After working for over a year alternating between two projects, one that uses Git for its version control and another that uses Mercurial , I have finally achieved sufficient mastery of both toolchains that I now feel comfortable defending my judgment that Mercurial is the superior of the two systems. I think Git has one glaring deficiency that makes it the inferior tool, and I hope to describe the required remedy in this weblog posting.The tools are very similar, and many of the distinguishing differences come down to a matter of taste in my opinion. Some may consider it a deal-breaker that Mercurial expects its extensions to be written in Python, whereas Git admits extensions written in just about any language you care to imagine, but the usual approach is to write them in a shell language. That's not a deal-breaker for me. Many other differences are either consequences of that fundamental distinction, or they are cosmetic in nature. It also bothers me not at all neither that Mercurial has no index, nor that Git has the index. The difference between the Git stash and Mercurial patch queues is similarly trivial to me.The big difference, the deal-maker for me, is in how each tool goes about meeting the fundamental requirement for any version control system: how it handles source code merging. Quite simply, Mercurial is better at merging than Git.I need to introduce a bit of terminology here to make my point. Because the literature for Git and Mercurial use the wordto mean crucially different things, I'm going to avoid the word here entirely so as to prevent confusion. For the concept described in the Git literature with the wordand in the Mercurial literature with the word, I shall use the word. I shall use the wordwhen referring to the concept the Mercurial literature usesto describe, which is a name that distinguishesMercurial is superior to Git because it recordshistory in the repository, while Git does not. In every other significant respect, a Git repository stores the same information as a Mercurial repository. This is why it is possible to convert a Git repository into a Mercurial repository then back into a Git repository without losing any information. It is not possible to perform this round-trip starting with a Mercurial repository (in the general case) because thehistory must be discarded in the conversion to Git. (In the conversion to Mercurial, the entire Git repository can be regarded as one monolithic, and indeed this is how the excellent Hg-Git tool presents its Mercurial view of Git repositories.)It turns out that having thehistory recorded in the repository— and thereby copied around with clones, pushes and pulls— is really important when reviewing the history of a project. A hint of this importance shows up in the cultural difference one observes between Git and Mercurial users.Among Git users, it's common to see people arguing vociferously that proper workflows involve judicious use of the "rebase" command to reduce the incidence of merging in the repository history. This is because Git only records theof every change, not its. When all you have to review in the history of a change is its, you don't want to be distracted by a lot of merges between differentin the same. In a Mercurial repository, because thehistory is recorded in the repository with every changeset, the urge to keep every pure from ancestor to descendant isn't quite as strong.In any sane Git workflow, there are two different ways to join a pair of divergent, "merge" and "rebase," and you'd better choose the right one at every opportunity or your whole team will lose valuable momentum dealing with their frustration with your bad version control hygiene. Always use "rebase" when thein your local clone is divergent from thein the upstream, i.e. more authoritative, clone. You do this so that the upstream clone can do a "fast-forward" merge when it pulls your change. It's important in Git for the merge not just to proceed without conflict; it must be a fast-forward merge in order to keep the authoritative"clean" of any evidence of your divergence.Basically, what's going on here is that Git encourages its users to adhere to a convention wherebyandare equivalent concepts. This leads to an aesthetic concern for "clean history" where every merge of two or moreis a record of the merging of thecorresponding to the. Anywith more than onehas a "dirty" or "unclean" history. Figuring out thehistory of any change in a Git repository where developers have not strictly adhered to this policy means a lot of guesswork. Consequently, some Git repository administrators set flags that enforce this convention, which leads to further confusion among users. "Why can't I push? Oh, you mean I should have rebased instead of merging? Foo."If you have a fetish for clean pedigrees, or you are using the Hg-Git bidirectional bridge, there is the standard "rebase" extension. It allows you to adopt a workflow that minimizes the incidence of merging betweenin the same. There is, however, not any compelling reason to do so: the repository retains thehistory. It's easy to review which changes belong to whichwhateverthey may have. Mercurial users therefore have no reason to be particularly diligent about maintaining "purity" ofhistories, as Git users do.I wrote at the outset of this article that I believe Git should be improved to remedy the deficiency I'm describing here. There are couple ways it could be done. One way would be to adopt Mercurial's style of annotating every node in the graph with aname. Another way— perhaps a more straightforward and "git-like" way— of dealing with it would be to annotate every edge in the graph with thename (derived from the branch name of the ancestor node in the repository where the commit occurred). You'd probably need a distinguished name for the case where thehistory is lost to antiquity.In any case, this is my argument for why Mercurial is superior to Git. You're welcome to your opinions, of course, but this one is mine. I'm open to persuasion that I'm DoingItWrong™, but it took me a long time to arrive at my judgment here, so please think through the arguments you want to make to me before you comment. Thanks.[Note: this article has been revised for clarity since its initial publication. The original draft improperly assumed the reader has a familiarity with Mercurial "branch" semantics. Some redundant assertions have been removed.]