15

Please note: I'm not trying to restart the argument whether Mercurial or Git is better, I just have a technical question that I, as a Mercurial user, don't understand. I'm also not sure whether SO is the right place to ask such a question, but it is programming related.

There have been many discussions about how the two version control systems Git and Mercurial differ from each other from a user's point of view (e.g. What is the Difference Between Mercurial and Git? and http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/ ), and the major difference is the handling of branches. I have read through many of these discussions, but I keep asking myself this question:

Why does Git not store the branch name as part of the commit?

I don't really see a good reason for not doing that; it means that data can't just simply vanish because there is no reference (tag, branch, whatever) poiting to it.

I see storing the branch in the commit as a big plus for Mercurial, because that makes it more difficult to lose data.

The main point of the Git crowd in favor of Git's branching model, that you can simply delete branches, does not prevent Git from storing the name of the branch as part of each commit: If the commits of a branch are deleted, so are the references to that branch. It will also not interfere with the "cheap branching" argument: branches will not be more expensive to manage. And I don't think that the additional storage needed should be of concern: it's just a couple of bytes per commit.

Community
  • 1
  • 1
daniel kullmann
  • 13,653
  • 8
  • 51
  • 67
  • I'm confused, when do you lose data at the moment? – Useless Oct 18 '11 at 13:28
  • 1
    I don't, but it's possible: As far as I understand, a detached head will be garbage-collected when you don't point a tag or a branch at it. – daniel kullmann Oct 18 '11 at 13:40
  • 1
    @danielkullmann: garbage-collected, yes, but not before at least two weeks: http://stackoverflow.com/questions/5772192/git-how-can-i-reconcile-detached-head-with-master-origin – VonC Oct 18 '11 at 13:50
  • 1
    @danielkullmann: That's why Git goes out of its way to warn you and keep you from doing that. It's really quite easy to always be working on a branch. – Cascabel Oct 18 '11 at 14:17

2 Answers2

16

One of the definitive source about branches for Git and Mercurial is the SO question:

"Git and Mercurial - Compare and Contrast"

In Git references (branches, remote-tracking branches and tags) reside outside DAG of commits.

(That allows to manage different namespaces regarding branches, for local and remote branches)

You have a similar notion with Mercurial with bookmark branches (which can be pushed/pulled).

Note that in Git, the data won't "vanish" because there is no reference: you still have the reflog to retrieve those unreferenced commits.

Why does Git not store the branch name as part of the commit?
I don't really see a good reason for not doing that

The idea is to separate what has changed (the commits) from whym ie from the context of the change (the name of the branch).
Since you can fast-forward merge a branch, commits from one branch can be part of another at any time.

That is why Jakub Narębski questioned the design of Mercurial "named branches" (with branch names embedded in changeset metadata), especially with a global namespace, not very suited for a distributed version control system.

You create a branch to isolate a development effort (see "When should you branch?"), but with a DVCS, that development effort (the set of commits) should be published under any branch name. What local context (branch name) you have defined might not be valid once published to another Git repo.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    I find it worrisome when people say "don't fear, that won't vanish; it's in the reflog". The reflog is temporary. It vanishes. After it vanishes, how do you get to the unreferenced parts of the commit graph? – Don Hatch Jul 31 '15 at 03:47
  • @DonHatch vanishes? Only after 90 days by default. If you really need that information after 90 days, I would assume that you can get it from a backup of your repo. – VonC Jul 31 '15 at 06:52
  • 3
    Sometimes I walk away from a project for 90 minutes, sometimes I walk away for 90 days. If information vanishes in the latter case, it means to me that that information is susceptible to vanishing and that in general it can't be relied on. In other VCSs, I often examine code history that's over 90 days old. The idea that some of this information would disappear after 90 days, and that I'd have to locate a backup of my repo in order to get at it, is a shocking proposition to me-- does it really sound reasonable to you? – Don Hatch Jul 31 '15 at 07:49
  • 1
    @DonHatch your code history will still be there. What won't be there is "unreferenced/unreachable" commits, that you didn't miss at the time (or you would has used the reflog *then*). As for the backup part, I have been working in enterprise environment for the past 15+ years, where backup is the name of the game when it comes for code referential. I understand it is not common for a personal use. – VonC Jul 31 '15 at 07:58
11

Mercurial’s basic model of operation is very simple, anonymous branches that form a directed acyclic graph (DAG), and as such branch names carry little importance and you will be dealing with them a lot less. Named branches are there mostly for organizational purposes (release branches, etc.), for which I would argue a global namespace makes more sense or at least is less objectionable.

Git has a more complicated and managed branching model than Mercurial, where even your local changes are treated like a separate named branch, and facing such a plethora of named branches you have to introduce namespaces to manage them. For the same reason Git has the concept of fast-forward merges, something that does not apply to Mercurial because you wouldn’t have created a separate branch in the first place.

Both these concepts add extra complexity, and at the same time block useful features like storing the branch name along with the commit. This is because you can not store namespaced branches without some global space, and git has none.

The flaw in the argument for namespaces that VonC referenced above is that it assumes there is a problem if you and I both create a branch called ‘x’. There isn’t, just like there is no problem when you create a named branch, merge it, and later create another one with the same name. A well-chosen name describes what the branch does no matter who the author is, and if you need to differentiate more the author is stored right along with the branch name, and all of this is permanent.

I think it was a very good decision of the Mercurial project to store the branch name along with the commit. Just like the commit message and the author, the context of the work (the branch) is important and useful meta-information. It makes it much easier to see the flow of the changesets when inspecting history, because you can see the context they were made in. In Git I have experienced that without this information, history quickly becomes a mess of jumbly lines that is hard to make heads or tails of. I think having this is well worth the trade-off of having no namespace.

I think you could say the philosophical difference is that Mercurial treats named branches as permanent meta-data that gives some extra information about a line of commits, whereas for Git branches are an un-versioned managing system for developers on top of the DAG. Mercurial also has these under the name ‘bookmarks’ by the way (as of version 1.8 a core feature), but they are really more of a tracking tool and treated like labels instead of branches.

Laurens Holst
  • 20,156
  • 2
  • 29
  • 33
  • How exactly are named branches in a global namespace not a problem? How can one later create another branch with the same name? Could you elaborate on that? Just as a side point: Mercurial (v5.4) itself, when creating a branch, points out: "branches are permanent and global, did you want a bookmark?" – Marvin H. May 17 '20 at 00:55