Re: What are branches?

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

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