Re: What are branches?

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

On 2009.04.20 16:25:38 +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? And about the ability to
> create new branches which point to the _exact_ same commit as other
> branches? And about the option to delete the original branch, not
> removing the commit, or the other branches, at all?
> 
> No, this all shows: we _have_ a different branch model from most other
> VCSes, and we _obviously_ make that not clear enough.

Basically, git has no actual entities that I'd call "branches", it just
has named branch heads. The branches themselves are implicit in the
commit DAG.

If you go out, and look at a tree lit-up by the evil daystar, branches
start at the trunk and end at their tip. The trunk isn't part of the
branch. And as e.g. a SVN user, you can use an analogy and say "There's
branch XYZ and it has these three commits", ignoring commits from the
trunk or other branches leading up to this one. And you can even ask SVN
which commits make up that branch, by using a "stop on copy" feature
(because that copy usually tells where the branching point is).

Let's take this history:

A---B---C---D (refs/heads/master)
 \
  E---F---G (refs/heads/foo)
       \
        H---I---J (refs/heads/bar)

The branches might be thought of to contain these commits:

master: A, B, C, D
foo: E, F, G
bar: H, I, J

Because those commits are (from a task oriented view) what makes those
branches. If branch "bar" implements feature Y, then the commits A, E
and F might not be interesting when talking about the branch in the
context of the feature it implements.

With SVN you could do:
svn log --stop-on-copy .../bar

Which automatically ignores commits that are on other branches.

With git you need:
git log foo..bar

Which gives the same result, but you need to be more explicit about what
you want to ignore. Because git just sees branch heads, not branches.
The same "you need to think a bit more/different" applies to merging
branches. As svn has just glorified cherry-picking, you can ignore the
whole history leading up to a branch, and still think of just "this
branch does this task", and "merge" that branch. For git, that obviously
won't do, you need to see the branch as it's embedded into the history.
I'm not saying this is bad, as it gives you a more useful history, and
more flexibility, but it is definitely different from at least one wide
spread system.

The only thing I'm aware of where git really draws a line between
"branches" and branch heads is git checkout. You can checkout a "branch"
using its name:
	git checkout master

But using the name of the branch head, will detach HEAD:
	git checkout refs/heads/master

(The quotes are there because this "branch" doesn't match the definition
of a branch as I used it earlier...)


So basically, we don't have explicit branches, just a mechanism to
control where the branches grow.

Björn