Re: What are branches?

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Apr 20, 2009, 16:06 UTC
Message-ID: <20090420160633.GA17241@atjola.homenet>
In-Reply-To: <alpine.DEB.1.00.0904201621290.6771@intel-tinevez-2-302>

On 2009.04.20 16:25:38 +0200, Johannes Schindelin wrote:

Show 12 quoted lines

> 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