Re: What are branches?

[Dmitry Potapov <dpotapov@gmail.com>]

On Mon, Apr 20, 2009 at 03:52:59PM +0200, Michael J Gruber wrote:
> Dmitry Potapov venit, vidit, dixit 20.04.2009 15:24:
> > On Mon, Apr 20, 2009 at 02:07:50PM +0200, Michael J Gruber wrote:
> >> Dmitry Potapov venit, vidit, dixit 20.04.2009 13:32:
> >>> On Sun, Apr 19, 2009 at 05:17:52PM +0200, Johannes Schindelin wrote:
> >>>>
> >>>> But it is important to keep in mind that our concept of branches is not 
> >>>> intuitive:
> >>>>
> >>>> http://longair.net/blog/2009/04/16/git-fetch-and-merge/
> >>>
> >>> I don't see how our concept of branches is any different from what other
> >>> version control systems have; but I see why it is so confusing for many
> >>
> >> It is very different, and for a good reason, indeed.
> >>
> >> git's branches really are moving tags. As such, there is no single
> >> branch that a commit would be tied to. A commit does not belong to a
> >> specific branch; you commit on a branch (usually), and it may be
> >> contained in 1 or more branches, of course.
> > 
> > When you create a new commit, it is always belong to _one_ branch and
> > never to two or more branches. After that you can create a child branch
> > that will also contain this commit, but it is so in any other VCS.
> 
> There is nothing in a git commit that ties it to a specific branch; in
> that sense, it does not "belong" to any.

Let's take a look at definition of "branch" in different sources:

"Branching, in revision control and software configuration management,
is the duplication of an object under revision control (such as a source
code file, or a directory tree) so that modifications can happen in
parallel along both branches."
Source: http://en.wikipedia.org/wiki/Branching_(software)

"This is the basic concept of a branch—namely, a line of development
that exists independently of another line, yet still shares a common
history if you look far enough back in time. A branch always begins life
as a copy of something, and moves on from there, generating its own
history."
Source: http://svnbook.red-bean.com/en/1.1/ch04.html#svn-ch-4-sect-1

"When we need to be precise, we will use the word "branch" to mean a
line of development, and "branch head" (or just "head") to mean a
reference to the most recent commit on a branch."
Source: http://www.kernel.org/pub/software/scm/git/docs/v1.6.2.3/user-manual.html#what-is-a-branch

It is not that Git commit is not belong to any, but it may appear as
being to many branches in shared history. Yet, I don't see anything
in definition of branch that would preclude this.

> 
> A git branch is a pointer to a commit. That commit and its predecessors
> are contained in the branch. A commit may be contained in multiple
> branches, on equal footing: there is no "prime branch".

This is not accurate description. The aforementioned pointer is called
"branch head". Branch (in strictly sense) is a line of development,
which is defined by its head. A usual commit has one parent; a merge
commit can have more than one parent, the first parent defines the
branch line while other parents point to branches merged to it.

> 
> In other VCS, a commit always belongs to exactly one branch: the one you
> committed it to, which is stored in the commit. It may be contained in
> multiple branches, but belongs to the one only.

I am not sure that it is the case, but actually it depends how you
define terms "belong", "contained", "branch", etc... Anyway, no commonly
used definition of "branch" implies any idea of exclusiveness ownership
of some commit.

> >>
> >> This is fundamentally different from what is named "branch" in hg, e.g.
> >> There, a commit stores the branch name, which is why you can't delete
> >> branches easily. [For me, this is also why hg branches are useless, but
> >> I don't want to start flames here - for me they are useless, for others
> >> they may still be perfect.]
> > 
> > I don't see it as fundamentally different. Basically, Hg has some
> > restriction that does not let you to remove branches that outlived their
> > usefulness (and thus polluting name space), but the underlying structure
> > is the same...
> 
> The underlying structure is the directed graph, with predecessorship
> being the incidence relation. But what's being discussed here is the
> various VCS concepts going by the name "branch" (the concept overlaying
> the graph structure), and those are inherently different. Not being able
> to delete a branch (without taking all its commits down) is one
> consequence of a specific concept.

I think you confuse two different things branch and its name. It is not
exactly same things in most VCSes, though you usually use branch name to
refer to any branch. In Git (as in CVS and SVN), you can delete branch
name without deleting commits.

> 
> So, that ID is exactly equivalent to hg's branch name: stored in the
> commit; just like svn's branches/paths if you follow a standard layout.

No, ID is just ID. You have commit ID in Git too, and you cannot remove
it without removing commits, and if you have commit ID of the branch
head, you can follow the whole branch line even if it does not have any
name.

> 
> > Incidentally, you can always follow Git branch
> > in similar way by using --first-parent option...
> > 
> >>
> >> Hg is introducing "bookmarks" now, corresponding to git branches. I
> >> think this name describes the nature of git branches very well.
> > 
> > Honestly, the first thing that comes to my mind when I hear bookmarks
> > in relation to VCS is unannotated tags... The idea of self advancing
> > bookmarks is really weird...
> 
> ... but exactly what git's branches are, and what makes them so useful ;)

No, Git branches are branches, anyway "bookmarks" is clearly a wrong
term. If you do not like "branch", there are many other terms that can
be used instead, for example: streams, codelines.

> That's because you're thinking of browser bookmarks instead of a real
> bookmark.  A bookmark in a book would be rather pointless if I couldn't
> advance it as I read pages.  :-D

You can advance them or move backward, but bookmarks do not move on its
own. They always point to the place where you put them. That's why this
term remembers me more unannotated tags.


Dmitry