The company I work for has decided to switch from CVS/SVN to Git, so I'm learning Git. I have previously worked with Mercurial, so you might think that it should be easy?!
One big difference between Git and other VCS is that Git has the concept of "staging" area. Before a file can be committed it must be staged. The advantage this gives (claimed by advocates of the staging concept) is that is gives you more control over what you commit.
I'm not that convinced... I think that the motivation for this concept is weak, and it introduces a complexity to Git that is totally unnecessary. My biggest motivation for this is: you should use a GUI! If you are a command line junkie you can stop reading now a go back to your black terminal window.
It is no convincidence that the GUI of both (Eclipse) Egit and Tortoisegit completely hides the staging concept. Why? Because there is no need for it when you can select what files to commit individually.
So maybe I was a little bit harsh about "command line junkies". I myself uses a command line when it is warranted. But I firmly believes that you should use a GUI when it is better. In this case it gives an overview and you are less likely to perform errors.
I was skeptical too, but I've found a variety of advantages to the Git index. You can not only choose which files to commit, but you can stage specific changes within each file. This is useful for making separate commits for bugfixes or different functionality within the same file; in other words, it's an atomization tool. You can even test your indexed changes before committing by running `git stash save --no-index` to stash everything that hasn't been staged. This is not possible without a separate index. It has nothing to do with GUI, and there's no reason at all that the GUI should hide the index from the user.
ReplyDeleteBTW, I think even a mouse-clicker like you should find that Git's powerful interactive commands such as `git add -i` and `git rebase -i` are just as easy to use as any GUI frontend. ;)