Re: What are branches?

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Apr 20, 2009, 12:07 UTC
Message-ID: <49EC6596.8060208@drmicha.warpmail.net>
In-Reply-To: <20090420113216.GC25059@dpotapov.dyndns.org>

Dmitry Potapov venit, vidit, dixit 20.04.2009 13:32:

Show 9 quoted lines

> 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. Which branch (name) may actually depend on the repository: branch names are not stored in commits, only (backward) relations between commits.

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.]

Branches in cvs etc. are much like the latter: You commit on a specific branch, *and* you can't change that later. The branch name at time of creating a commit is stored in the commit.

Hg is introducing "bookmarks" now, corresponding to git branches. I think this name describes the nature of git branches very well.

Show 46 quoted lines

> people. We define a branch as a line of development (I'm still think it
> is a pretty good and widely accepted definition of branch), yet when a
> newcomer runs gitk, what he or she sees is not a line but a graph.
> 
> Thus anyone looking at a gitk image may ask you: "Where is this line
> that represents the master branch?" Indeed, it is nearly impossible to
> see it, but it does not mean this line does not exist. If you run:
> gitk --first-parent master
> you can see it.
> 
> Unfortunately, this line is far from being one straight line drawn in
> a single color. Thus, not surprisingly that this line cannot be seen in
> the graph, and here is where the mental image that a new user has about
> branches (based on different books and diagrams) clashes with the image
> presented by gitk. No one will ever draw the mainline like this:
> 
> -o--o--o         o--o--o
>         \       /
>          o--o--o
> 
> but it is not uncommon for gitk to display it in this way, and when
> this line is intervene with many other branches that forking from and
> merging to this mainline, all what you can see a complex graph and
> nothing more.
> 
> There is one more thing. In Git, all branches are equal and that is a
> really good feature from the implementation point of view as it makes
> design simpler and more powerful. But the user point of view, branches
> are never equal -- there is a _big_ difference between the master and
> any feature branch. All diagrams explaining branching and merging will
> show the mainline as a thick straight line running through all history
> (like a tree trunk) while feature branches fork and merge back to it.
> 
> That is the mental image that a new user has, and that image clashes
> with what he or she sees in gitk. BTW, when I started to use Git, I
> strongly preferred qgit over gitk. Admittedly, gitk displays branches
> much better when you have a really bushy tree, but straight lines
> displayed by qgit were much easier to understand and to follow.
> 
> So, I don't think that we have any conceptual problem here. It may be
> a visualization problem, but if you have a really complex tree, it may
> be impossible to present it as nice and simple as artificial diagrams
> in textbooks.
> 
> 
> Dmitry