On Fri, 29 Jan 2010, Ron Garret wrote: > In article <7vbpgc8fhb.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>, > Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > "A commit that is in the middle of an ancestry chain with existing > > descendants" can be at the tip of a branch and does not have anything to > > do with detached HEAD state. > > Ah, then you're right. I really don't get it yet. Have a look at http://eagain.net/articles/git-for-computer-scientists/ That's one of the clearest explanation of the Git branching model I've seen. > > When HEAD points at a branch, making a commit advances _that_ branch. And > > we say you are "on that branch". When HEAD is detached, because it is not > > attached to anything, it advances no branch. "detached HEAD" is detached > > in the very real sense. It is not attached to _any_ branch. > > OK. The docs do not make that clear at all. In fact, the following > statement, copied straight from the manual, flatly contradicts what you > just said: > > "The special symbol "HEAD" can always be used to refer to the current > branch." > > Always. Except when it can't. There is no contradiction. The "detached HEAD" corresponds to HEAD pointing at no branch in particular. There is just no current branch in that case. > Soooo..... > > Sometimes HEAD can refer to a branch head which is a pointer to a > commit, and sometimes HEAD can refer to a commit directly without > indirecting through a branch head (lower case), in which case it is > detached. Is that right? Exact. > If that's true, then I'm back to wondering what good is a detached head. > Why would you ever want one? What can you do with a detached head that > you could not do just as easily without one? By definition, remote tracking branches are "read-only" because we want those branch heads to reflect what the remote repository they're tracking has. In other words, you're not supposed to add commits to a remote branch or it would move that branch to the new commit which is no longer a representation of the corresponding remote repository. In order to actually add commits on top of a remote branch, you first have to make a local branch being a copy of the remote branch of interest (which in practice means only making the local branch point at the same commit node as the remote branch) and then any commit will advance that local branch and leave the remote branch behind. But what if you just want to check out the content corresponding to that remote branch without adding any new commits? What if you wish to do the same with a tag instead of a branch (a tag being immutable)? If you could have HEAD pointing to a tag or a remote branch then many operations such as 'git commit' would need to be blocked in order to preserve the read-only nature of such references. The detached HEAD solves the issue really neatly in those cases. Instead of having HEAD pointing to a remote branch record, the detached HEAD points directly at the provided commit from the remote branch head or tag, and any commit operation will simply update that direct reference alone, creating a fork point in the history graph. If you wish to preserve this branch in the graph sense then you can create a new branch head with the current HEAD position. Or if you don't care about those commits you made on the detached HEAD, then simply moving HEAD to anything else with another checkout command will drop and forget about that string of commits you created. So a detached HEAD is useful for checking out a read-only branch or tag without having to forbid a bunch of operations or needing for you to create a dummy temporary local branch just for the purpose of such a checkout. Many operations with intermediate states such as 'git rebase' or 'git bisect' can be implemented without polluting the branch namespace, etc. Nicolas -- 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