The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Learning curve: Two miles through the snow, uphill, both ways.
But then: enlightment.
I was lucky, had someone to hold my hand, still took me some weeks of daily use to get used to it.
It is a pinnacle of "developers aren't users" software, so yeah, I see you pain. Yet I do not want to miss the workflow anymore I can have with git. All attempts to plaster a decent UI on top of it somehow make it worse, though.
Fortunately, I do to, but I work at home and my client works at home, and we don't live in the same home, so often enough I have to figure things out on my own. Worse thing is, I thought I had it under control, but then discovered something yesterday that I couldn't work around.
My solution? Deleted the whole project and re-cloned it from the remote. Maybe that's what I'll just do as s.o.p, hahaha.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DDEthel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
In my case, no, because it's a Ruby on Rails app, and I'm using RubyMine as the editor (pretty slick product) but it's figuring out RM's support of Git without first understanding how to use Git from the command line is not a good idea. Once I get the command line stuff under my belt, then I can poke around RM's GUI support and see what it's doing (it has a nice display of what it's telling Git to do.)
Git and SVN solve different problems. You should use the one most suited to your current project/needs. SVN is a centralized whereas Git is a distributed. With SVN, you have a local working copy and with Git you have a local repository. It is for this reason it may seem that Git is overly complex. If you want to fork a repo and add features that will be different from the projects original goals then Git might just work best for you. If you want a group of individuals contributing to a common code base then SVN will be your best bet.
I strongly disagree with you guys.
I have working with Git and SVN for quite a while - in different environments and at different companies, and I prefer Git to SVN.
At the end of the day - I found that Git is much stronger and you are able to do so much more with it that thing SVN. Yes sure to get to all the nice interesting stuff it takes some understanding - but if you think about it development is the same. If you think you will become a developer with only a bit of understanding of general concepts you are wrong. <-- this is especially to all the Graphic Designer who this that they are developers thanks to WordPress and Drupal
Git is not all that complex and the features (pros) out way the learning curve (cons) I would say.
I am not saying that there is something wrong with SVN or that Git is better - it different and its all dependent on what you want to do, and how much you are willing to learn.
The problem with Git is that Linus has been quoted in saying something along the lines of "Git isn't a tool [solution], it's a framework." This lead me to believe that you should really have a few scripts set up that do the heavy-lifting for you. SVN is a tool, it does what it is designed for and nothing more: by using SVN you subscribe the workflow imposed by the SVN developers and have no versatility, where Git can be jimmied into basically any workflow.
GitHub for Windows also gets rid of a lot of the pain (really, one-click pushing and pulling) - and it isn't only for GitHub repositories[^]. In a similar light, Microsoft have released the GitHub integration for Visual Studio and I assume it will be of the same caliber (read: simplicity) as TFS.
I only drop to the CLI when I really need to these days, and haven't needed to in a couple of months: the Windows tooling is great for it, if you know it's there.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chinese Proverb]
The biggest potential problem with version control is when people don't use it frequently. People won't use frequently what isn't easy to understand and use. For that reason, if for no other, Subversion >> GIT.
If you're working on your own, or within a team where every single member understands how and loves to use GIT, then all the power to you. But if you have only one member in your team that isn't comfortable with it, you're going to have problems, sooner or later.
So I'm not alone - thanks for making me feel better about that!
Overall I find most source control a pain (and worry), when they should make life easier. Maybe it's a lack of trust on my part, but I still do a time stamped batch file backup of the source irrespective of using a source control (not GIT!)
As for GIT, I just find it too complicated - which means it has a low trust rating in my book, if you can't easily understand a system how can you trust it? As one of our engineers said it must have been named after the characteristics of one (or all) of its designers!
it's my understanding that git is meant to manage multiple branches easily, probably that's why is overly complex for simpler tasks like working in a one shared source tree.
Yes, I would agree. I can see where my idea of working with revision control is different. I rarely would branch my SVN tree, and the idea of keeping local a local repository with all of the local branches and changes on my computer (until they are pushed onto the remote repository) I can see as possibly beneficial but overly complex, and frankly, scares me a bit with regards to losing my work due to a disk failure or the complexity of merging my work if I fall too far behind everyone else's branches.
However, having read something recently, I am beginning to change the mental picture I have been holding - namely, that there is also a local repository as well as a remote repository. That helps me understand why a commit doesn't actually get seen on the remote server until a push happens.
It looks like you just do not need it. JIT has just 2 strong points - distributed architecture and conflict resolution. You use "I" and not "we" in the post, so it is unlikely that you can benefit from either. Besides these 2 advantages, GIT still retains its nature of a quick hack. I guess this happens because the focus is still on making things possible as opposed to making them easy or forgiving.
You use "I" and not "we" in the post, so it is unlikely that you can benefit from either.
Well, this IS for a project with a couple other devs on it.
I guess this happens because the focus is still on making things possible as opposed to making them easy or forgiving.
Those are not mutually exclusive. My client is an expert at Git and whenever he explains something, it all makes sense and I "get it", but then when I try to do something at home, it blows up for me. It's a learning curve, and I've read through books and blog posts, but there is still a disconnect between what I do, that I think is doing it right, and what ends up happening. However, my rant was at the fact that I tried to do everything possible to kill my changes and revert back to the remote repository, to absolutely no avail. I ended up deleting the entire folder and re-cloning it. When I read in the documentation that doing a "reset --hard" (or whatever the syntax is) should kill my local changes, and doing a fetch / pull / checkout should get me to the latest version on the remote, and it obviously didn't work because "git status" still returned all the changes I wanted to throw away, then yes, I rapidly come to the conclusion that it's a pile of s***.
In a sense, yes, it is that pile. When I started using GIT I created a 3 repository model of the real project and tried commands there first. We also had few developers, but thanks to the lack of coordination and frequent changes in specs and overall project direction GIT payed for itself. I guess that was what a much larger and better organized team would experience.
From the perspective of someone at the other end of the experience curve, I found Git almost impenetrable - I'm learning French right now (and I'm not a young whipper snapper), Git is harder than an entirely new language as far as I'm concerned.
I would guess that if I broke through that outer shell and was already experienced with VCS concepts then Git would be the best choice - it's an assumption since why else would so many people and companies flock to it? I am guessing that the complexity pays back later when you have lots of contributors, branches etc. and maybe Bazaar, Mercurial etc. aren't so capable at that stage..., I have no idea, but there must be some reason!
However, the most frequent comment I see and which tallies with my own experience, is "If it was my choice I'd use Mercurial".
Mercurial is so much easier to get your head around, hugely helped by TortoiseHg, from total novice to functional in minutes not years.