On 2009.04.20 22:47:46 +0400, Dmitry Potapov wrote: > On Mon, Apr 20, 2009 at 04:25:38PM +0200, Johannes Schindelin wrote: > > > > On Mon, 20 Apr 2009, Dmitry Potapov wrote: > > > > > When you create a new commit, it is always belong to _one_ branch and > > > never to two or more branches. > > > > Certainly you forgot about detached HEADs? > > I suppose it is a branch without any name given to it, Strictly, you don't give names to branches with git. But if you do, that has some "interesting" consequences. Let's say you have "master" checked out and do: git branch foo git checkout -b bar You now have a single line of development and three names that reference it. So your branch would have three names, right? git commit --allow-empty -m 123 Now, your previous branch only has two names left, and you have a new branch with a single name. git reset foo And now, you again have three names for the original branch and the new branch is unnamed. So when you go and say that branch heads provide names for branches, your actions become pretty weird. "git branch <name>" gives new names to existing branches, and "git commit" is what actually creates the branch (this is always the case), plus it might remove a name from an existing branch. "git reset" removes a name from one branch and gives it to another branch. "git rebase" does the same, and it's in general not valid to think of rebase as rewriting the branch's history. For example: git checkout -b for-v2 for-v1 git rebase --onto v2 v1 for-v2 That would create a new branch, add for-v2 as a name for it and remove the for-v2 name from the old branch (so the number of names for it is reduced by one, but it's still called for-v1) So, IMHO, if you think the whole "branches have names" scheme through, using the "a branch is a line of development" definition and keeping in mind how git actually works, using branch heads, things do get pretty confusing. > but it is an advanced feature. I don't think many beginners know about > it, so it is something that can confuse beginners. But it should not. In my experience, telling someone how HEAD works often leads to some kind of epiphany. And a detached HEAD is probably easier to grasp than the "normal" situation where HEAD is a symbolic reference to some branch head. Btw, writing those emails, I can now understand _why_ the explanation of HEAD and how it controls which reference gets updated upon e.g. "git commit" might be so helpful to some users. It might just be the fact that they suddenly realize that git does not have a true directly user-accesible notion of branches, but just branch heads. I can imagine how users that think in branches that have a start and an end might get confused. Björn -- 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