> "master" is nothing more than a pointer to a > particular commit. The commit has references > to its parent(s), from which you can build a > whole history. In general, Git doesn't > know the name of the branch a developer had > checked out when a commit was created. > In fact, in this example, both branches > could have been called "master" if they > lived in different developers' workspaces. I understand. However, let's see if git can cope with this pretty common scenario: Say I'm a developer with too many projects and little time. I don't really want to find the commit ID at each release and manually make a note on the project's web site. In fact, I have no "official" releases. The "contract" with my users (or co-developers in my team) is simple: check out HEAD, it should always work. If it doesn't, last week it worked well, check out at that point in time and wait until I fix the HEAD. Now you're saying I cannot reliably checkout last week's versions because yesterday I did a merge from an older branch? You mean that git stores everything with clean graphs and numeric pointers, so it cannot know what this repository looked like last week? As the developer, I have full control, I can decide what the branches are called and how the public repository is updated/pushed/whatever. I can control the clock so there are no time skews. What do I have to do in order to be able to reliably checkout last week's versions without too much administrative work? I just want to get the same result today as if I had done a checkout last week from the public repository and had made a back-up copy of the working directory then. With say CVS and Subversion, that's piece of cake, they already work that way, I don't need to manually keep track of revision IDs or visually inspect the merge tree. Thanks for your answers, R. Diez -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html