It seems most people understand add and commit, but few understand reset and checkout. For example, the author of “Pro Git” (http://progit.org/book/ch1-3.html) explains checkout incorrectly (as from repository to working) in Figure 1-6.

I think the command names are a major factor in the widespread misunderstanding. The word checkout implies getting a fresh copy of the last version checked in. You don’t need experience using CVS to have that impression. Experience using a library will do.

I don’t think I have ever seen reset explained as you have explained it. It is pretty hard to come up with that understanding from the man page: “git-reset: Reset current HEAD to the specified state. Description: Sets the current head to the specified commit and optionally resets the index and working tree to match.” That is misleading given that the default behavior is to reset the index, with an option to also reset the working tree (–hard), or reset neither (–soft).

Here is one series of events that is totally confusing if you don’t understand the git index:

1) modify a file
2) add it to the index in preparation for a commit
3) change your mind about committing the change
4) now try to revert to the original version of the file by checking it out again

Checking out again will not “revert” the changes, because the changes are already in the index and checkout causes working to match index. You have to reset index from repository, then checkout from index to working. If you dig around, you’ll find there are commands that do both (reset –hard, and commit -f) but to the uninitiated, those just make the git index harder to understand.

What ‘git checkout’ *actually* does (RTFM) when given a path is to replace the working copy file with the version of that file currently in the _index_. If you haven’t modified the version in the index since you switched branches, then you’ll get the same result as ’svn revert’. To achieve the same result as ’svn revert’ in all situations, you would first need to ‘git reset’ the file to replace the version in the index with the version from the current HEAD (which would be the commit to which you went “back in time”) and then ‘git checkout’ to replace the file in your working copy with the version in the index.

Git makes a lot more sense once you realize that data _never_ moves between the working copy and the repository directly — in either direction. It always goes through the index: ‘git reset’ copies from the repository to the index, ‘git checkout’ copies from the index to the working copy, ‘git add’ copies from the working copy to the index, and ‘git commit’ copies from the index to the repository.

It might also be worth mentioning that ‘git reset –hard <commit>’ and ‘git checkout -f <commit>’ do almost the same thing. Specifically, they both: update the ‘HEAD’ ref to point at the specified commit, reset the index to the contents of that commit, and check out the index into the working tree. The difference is that ‘reset’ also updates the ref of the branch that you were on, if any.

When talking about Git’s usability Ian complains that Git installs “nearly 150 distinct binaries” and claims that “Mercurial has one.” What Ian doesn’t mention is that while Git may install nearly 150 files you only have to reference one of them directly just like Mercurial which installs over 150 files (a number which roughly doubles as each .py file begets a binary .pyc file after it gets executed).

Yes, but while I haven’t used Mercurial, I suspect those go into some Mercurial-specific folder. Git dumps all those git-* commands into bin/.

For my “work” machine, I don’t have root, so I have a bunch of stuff installed with a prefix of ~/.local. And I actually have a separate bin directory just for Git so that I can do an ls ~/.local/bin and not have 2/3 of the output be Git stuff.

So if I’m right, Mercurial may indeed install 150 Python files, but it probably does it in a less obnoxious way.

“When you “revert changes to a small number of files” Git, like any other version control system, gets a copy from the repository, and what do you call the action of getting files from a repository? That’s right kids, “checking out”.”

No, that’s not true. For instance, take SVN. If you want to revert changes to a small number of files, you use svn revert, which simply reverts the changes. It does NOT contact the repository, at least in the SVN sense of a repository.

This is both a minor quibble and an important difference. It’s a minor quibble because in some sense it does contact the repository — it’s just that the repository has a single version of the tree, and it’s the version you got when you last did svn update. And the repository it accesses happens to be stored in the .svn directories locally instead of what you (read: an SVN user) typically think of the repository as.

But at the same time there is an important difference. If you do a git checkout, you get the head of the branch you specify. But if you do svn revert, you get the revision of the file that you last requested. So if I deliberately go back in time with ’svn update -r 287′ and change a file, I can ’svn revert’ and I have the file as it was in revision 287. In Git, if I deliberately go back in time with ‘git checkout 4dfa983d’, change a file, and want to revert it, from my reading I have to figure out that my working copy is based on the revision with hash 4dfa983d and then explicitly request that with the next checkout.

In other words, if I’m working on ‘master’ and do ‘git checkout master’ to revert changes to a file, that’s like doing an ’svn revert’ then ’svn update’.

I think that Ian said Git is seen as a “framework to create your own workflow”. That sounds pretty scary. I need an RCS – not a framework either. If that would rather point out that Git is flexible but you are not forced to do that (similarly to that you are not forced to use “git rebase” unless you see a need) then it would sound much nicer. But if I start going through the tutorial and find myself not understanding even parts of the newbie tutorial then I’m severely screwed. I think “rebase” was one of the features that left me puzzled and made me keep using Mercurial because that was simple enough and didn’t force me to learn new features that I had never missed before. I think I’ll give Git another try.

1) Git is harder to use because it’s better — the Blub argument. That would be an argument for Git over, say, Subversion, but not so much over Mercurial. Git and Mercurial are quite similar in power. Git can do some things that would be difficult or impossible in Mercurial, but there is far more overlap than difference.

2) Usability. It’s true that if you turn on lots of extensions in Mercurial, you can tamper more invasively with history. (I could perhaps be forgiven for having the misapprehension that git-rebase is a command intended for everyday use, since nearly every tutorial seems to mention and encourage its use.) Even so, I find that the exposure of all Git’s commands at the top level gets in the way of finding the command I need. And doing simple things like cloning into a bare repo and then doing a git-fetch should be, well, simpler.

3) Reliability. That was an error on my part. I lost data (on a backed-up project, of course), but looking back, this seems to have been due to user traps (or pilot error, if you’re less charitable), and not in some underlying data flakiness.

Again, I’m not seeking to re-ignite the argument. Quite the contrary — I’m going back and attempting to correct my misunderstandings. But your post deserved a response. So: thanks. Looking forward to hearing more about the book.