Checking out a old commit erases the new one in git - why?

I have just made a new git repo. I created a couple of files, added them to the repo and them commited it. I then added a couple of new other files, added them to git and them commited again.

To my surprise, if I try to checkout the initial commit, it will erase the new one(at least that's what it looks like). In the egit window that appears while the operation is accomplished, it says something about "performing branch to null".

I've tried this 3 times and it always happens, so I guess this is indeed intended behaviour. Could anyone care to explain why does this happe开发者_如何学编程n? What is the rationale behind it?

Thanks

When you check out the old commit, it is not erasing the new files, but instead moving your working copy back to the old version. For instance, your history may look something like this:

Refs:              v-- master <-- HEAD   
Commits:    1      2 
          --*------* 
Files:      |      |
            +- foo + foo
            +- bar + bar
                   + baz

This indicates that you have two commits, 1 and 2 (of course, they will be long hex strings, but we'll call them 1 and 2 to make it easier). In commit 1, you have files foo and bar. In commit 2, you add a file baz. Now, if you check out commit 1, that means you want to switch your working tree to look exactly like what's in commit 1, updating your HEAD ref to point at it:

Refs:       v-- HEAD v-- master                       
Commits:    1        2  
          --*--------* 
Files:      |        |
            +- foo   + foo
            +- bar   + bar
                     + baz

So now your working tree looks just like it did in commit 1; you only have foo and bar. If you check out master or commit 2 again, you should see baz reappear.

Does this answer your question? I'm not quite sure why you would want to be checking out commit 1 and not have the directory contents appear as they do in commit 1, so maybe I am misunderstanding your question.

Note that you might get a warning, if checking out commit 1, that you will wind up with a detached head. A detached head is a HEAD ref that doesn't point at a branch. If you have a detached head, then any new commits that you create will not be referenced by a particular branch; they will only be referenced by your HEAD, which means that if you later check out master or another branch, there will be nothing referring to them (other than the reflog).

Also, when you check out commit 1, if you then do a git log to look at the history, it will by default show you the history of the current HEAD revision (that is, the version you currently have checked out). Since this points at revision 1, which has nothing else in its history, you will only see revision 1 in the history. You can still see the history of other revisions by referring to them directly or via refs that point to them, like master. In my example above, if you did git log master, you would see a history containing commits 1 and 2.

In order to see the full history of your repo, I generally use gitk --all, to show me all of the branches, tags, and other refs in my repository, along with their history. You mentioned that you are using EGit, which I'm not familiar with, but it may have a similar "show all history" option.