Mercurial vs Git: Why Mercurial?

This is a guest blog post by Steve Losh focusing on the primary reasons a team may choose Mercurial as their (distributed) version control system. Check out Steve’s projects to see some of the cool things he has worked on around Distributed Version Control, or jump over to his Bitbucket account and fork one of his many projects.

There are two major distributed version control systems in widespread use today: Mercurial (Hg) and Git. There are many reasons (and opinions) why one would choose Git or Hg, and the next two blog posts in this series aim to explain some of these Whys.

A Sane Command Line Interface

The command line interface is the first thing many programmers will see when using a new version control system. Mercurial’s CLI is full-featured, stable, and elegant. It follows the UNIX philosophy: “each command should do one thing and do it well.”

Git’s CLI is designed to be extremely flexible. Each command has many options that can change its behavior. This makes for less typing, but requires you to remember all of the various options and how they interact with each other. Git’s documentation must detail all the interactions between options, which makes it more verbose and difficult to skim.

Mercurial’s simple approach leads to documentation which is sleek and concise. It’s easy to find what you’re looking for — using hg help, so you can spend less time looking at docs and get back to coding. It favors clarity over “cleverness”, which makes for an easier-to-use tool.

Mercurial tries to be helpful by anticipating some of the more common aliases for commands and just making them work. For example, the hg rename command can also be run with hg move or hg mv. Git simply gives you a git mv command. You can create your own git move alias if you like, but that’s yet another step to try to make Git’s CLI pleasant to use while Mercurial’s is pleasant by default.

Mercurial’s CLI is also quite similar to Subversion’s, which can help ease the transition between the two tools. Here’s a comparison of some of the most common commands. Mercurial/Git commands that are the same as their Subversion equivalents are bold.

Subversion (SVN)

Mercurial (Hg)

Git

svn add

hg add

git add

svn blame

hg blame

git blame

svn cat

hg cat

git show

svn checkout

hg clone

git clone

svn commit

hg commit ; hg push

git commit -a ; git push

svn delete/remove

hg remove

git rm

svn diff

hg diff

git diff, git diff –cached

svn help

hg help

git help

svn log

hg log

git log

svn revert

hg revert

git checkout -f

svn status

hg status

git status

svn update

hg pull –update

git pull

svn move/rename

hg move/rename

git mv

As you can see, Git makes less of an effort to organize its CLI in a way that Subverison users will be used to. While you can work around this by retraining your fingers to type the new commands, it’s yet one more roadblock to switching systems. Worse, it simply isn’t necessary, as Mercurial’s Subversion-user-friendly but still powerful and elegant interface proves.

Safer History with Mercurial

Mercurial’s philosophy is that “history is permanent and sacred.” Core Mercurial includes only one single command that can alter history: hg rollback. This command will “undo” the last pull or commit, but will never touch anything further back.

Git, on the other hand, lets you play fast and loose with your project’s history. Commands like git rebase –interactive let you rewrite history, possibly discarding data along the way.

Yes, you can find changesets you’ve destroyed through git rebase –interactive using git reflog, but if it has been more than a month since you made the change, those changesets will be lost (Git will “garbage collect” these changesets after a month).

Including destructive commands in core means new users are more likely to shoot themselves in the foot by running commands with implications they don’t fully understand.

For the times when you do need to rewrite history in Mercurial, you can turn to extensions like collapse, histedit and MQ. Keeping this functionality out of core prevents new users from accidentally using it until they’re ready.

Most of these extensions will also permanently back up any changesets that they destroy into a bundle. These bundles will not be garbage collected, so you don’t have to worry about your version control system eating your data.

GUI Support

Many programmers prefer to use a graphical interface to their version control system instead of working through a command line. Several third-party GUIs have been created to make working with Mercurial easier.

One of the tools out there is SourceTree, a free Git and Mercurial Mac client offered by Atlassian. SourceTree is an easy-to-use app that connects to many of the popular source code hosting tools out there like Bitbucket, Kiln and (for Git users) GitHub.

TortoiseHg is another available tool — a shell extension for Windows, Linux and OS X that provides a mature, stable GUI to work with Mercurial. Programmers familiar with TortoiseSVN or TortoiseCVS will feel right at home working with TortoiseHg.

If you use the popular Eclipse IDE for your development, there is a plugin called MercurialEclipse that integrates Mercurial into Eclipse, so you never even need to leave your IDE.

Windows Support

With Mercurial, Windows support is a first-class feature. The Mercurial crew cares about Windows users and is very concerned with being completely cross-platform. You can build core Mercurial from source on a Windows machine and use it without having to rely on prepackaged binaries if you like.

Git, on the other hand, does not provide support for Windows in its core code. There is a project called msysgit that adds compatibility for Windows. However, it is commonly reported to be slower than Git on Linux, and the fact that it is a completely separate project says something about Git’s attitude toward Windows use.

Backwards Compatibility

The maintainer (and original author) of Mercurial, Matt Mackall, is a strong proponent of backwards compatibility, which is important when you’re choosing a version control system that you plan to rely on for a long time.

Easy to Extend

Once you get comfortable working with Mercurial, you’ll probably find features that you wish it had. You could talk to the Mercurial developers and try to get someone to implement these features, but that can take a lot of time and effort (and they may decide they don’t want the feature at all).

Mercurial knows that everyone is going to have different needs, so it provides several ways to extend its functionality without changing the core code.

The first method of extending Mercurial is writing shell scripts that call its command line interface. The output of most Mercurial commands is in a “human-readable-but-easy-to-parse” format. It’s often quite simple to write a shell script to do what you need. For example, say you’d like to add a command to automatically paste your current diff to http://dpaste.com. You could write a tiny shell script called “hgpastediff” to do it:

123456789101112

#!/usr/bin/env bash
hg diff | curl -si -F 'content=

Once that script is on your path you can simply run <code>hgdiffpaste</code> to paste the code to dpaste, and the location of the paste will be printed for you.

As we mentioned in the last section, Mercurial is committed to maintaining a backwards-compatible command line interface, so you'll almost never have to worry about your shell scripts breaking when you update to a new version.

Another way to extend Mercurial is to use aliases. Aliases let you define new Mercurial commands that run other commands, possibly with arguments. For example, if you work with someone named Alice and merge with her often, you may find yourself typing <em>hg commit --message "Merge with Alice."</em> often. You can define an alias in your <em>~/.hgrc</em> file to cut down on this typing:

[cc lang="xml"]
[alias]
mwa = commit -m "Merge with Alice."

The 1.7 version of Mercurial included a feature called “shell aliases” that lets you define aliases to run shell commands. We could avoid creating a separate shell script file for our “paste to dpaste” feature by using a shell alias:

[cc lang=”xml”]
[alias]
diffpaste = !hg diff | curl -si -F ‘content=

Shell aliases are a quick and dirty way to make new commands that make your life easier.

Sometimes a shell script is just not powerful enough to add a feature you’d like to see in Mercurial. When that happens, you can write your own Mercurial extension using the extension API. Extensions are written in Python (like Mercurial itself), which is a very common and elegant programming language.

Writing extensions gives you full access to all of Mercurial’s internals, which means you can do just about anything you can imagine.

Commercial Support

With a tool as important as a version control system, it’s important to be able to get support when something goes wrong. It’s also helpful to be able to pay for professional training if you don’t have any experienced users in your company already.

There are several places to turn to for Mercurial support and training. The most up-to-date list is the Support page on the Mercurial wiki.

Another place to find information about professional Mercurial consulting is the newly created mercurial-consulting mailing list. If you have specific needs, the mailing list would be the best place to ask.

Hosting Tools and Services

Programmers almost never work alone, and it’s often beneficial to have a central copy of your repositories that can be browsed easily on the web. There are several ways to make this happen.

The hg serve command fires up a web server on your local computer that other people can view in a browser and pull from. For sharing changes with another person quickly, it couldn’t be easier. For a more secure and permanent server, you’ve got a couple of choices.

Mercurial bundles a repository-serving script similar to hg serve that may fill the needs of smaller companies who just need a way to share links between people. It can run on most servers that support WSGI, and it is included with Mercurial itself.

Atlassian’s Bitbucket is a hosted service for Git and Mercurial that will host your repositories and provide many more features than the standard Mercurial web server. Plans are free for 5 users and priced for higher user tiers thereafter – with an option for unlimited private repositories available. Using Bitbucket means you don’t need to worry about buying new hard drives to host your projects or setting up new web servers for them. Bitbucket gives you an interface that “just works.”

There is also Atlassian’s FishEye which allows you to browse and search repositories in Git, Mercurial, Subversion, or any of the other supported systems — all configured within a single installation. FishEye can connect to a Bitbucket repo to give you advanced browsing and search capabilities as well. If you want a bit more out of your code review process, you can tack on the Crucible product to FishEye as well.

Bitbucket and FishEye both connect to popular issue tracking tools like JIRA or Bugzilla.

Mercurial or Git?

Now that we have given you a few reasons for Mercurial, you may want to consider using a distributed version control system. In our next blog, we’ll take a look at the advantages of using Git.

Comment and let us know if you chose Mercurial – we would love to hear why and I am sure many readers would as well. If you opted not to use Hg, we’d love to hear why not as well.

You should also mention JGit (http://eclipse.org/jgit) which implements Git and allows it to run anywhere the JVM can. This essentially makes Git cross-platform. It’s used by the variety of IDEs out there to work with Git and also by code review tools like Gerrit.

How is JGit from the command line? They’re website makes it look like it’s really only useful as a library for embedding into other programs.

By balor123 on February 23, 2012

Well, the article glimpsed over the Windows issue quite fast. I understand why: performance of Git for Windows is not slower on Windows than Linux because *Git* is slower, but because the file system layer is slower. That is true for Python in general, and Java, too.

Having said that, I do agree that the support for Windows in Git is a second class citizen.

And I am also envious of Mercurial’s cleanness of user interface.

In general, however, I think that the differences between Hg and Git are rather cosmetic. To me, it is no problem to use either.

So you have still all of the files in the repository, but only update the working copy to a specific subset. This is achievable with core Hg with a partial revert, followed by partial commits.

In addition, there is an extension (narrow) to filter the manifest in such a way, that the “ignored” files do not appear as if under version control. I think this is equivalent to git-read-tree.

The use-case for this feature is rather limited IMHO. Narrow CLONES, on the other hand, would be something interesting, though…

By Face on February 23, 2012

The use-case for this feature is the one that I described – loads of tiny files that don’t take up a lot of space but which take a long time to manipulate on disks. That occurs commonly on projects with lots of tests, particularly when the test cases are generated by customers.

Partial reversion isn’t the same because you have to pay the cost of creating all the files first before you can hide them all and the point of partial checkout is to save all that time.

I can’t find this narrow extension that you are referring to. Can you provide a link? In any case, extensions don’t cut it for corporate environments because they are far less likely to be maintained than core projects.

Narrow clones would be even nicer but I don’t think we’re going to get that any time soon. It seems to have been discussed for most of Mercurial, Git, and Bazaar’s lives and it hasn’t happened yet. Git is the only one to get partial checkout support and it took years for a very simple implementation to appear. The interface still stinks too – I’d like to just run git checkout rather than editing a file in some obscure location and following up with a series of commands.

By balor123 on February 23, 2012

> Partial reversion isn’t the same because you have to pay the cost of
> creating all the files first before you can hide them all and the point of
> partial checkout is to save all that time.

Well, you can clone without update, and then “hg revert -r [revision] -I [filepattern]”. That will get you nothing but the files specified into your working-copy. You can even change the parent revision without updating files with “hg debugsetparents [revision]” followed by “hg debugrebuildstate”. This looks ugly, but TBH not worse than that man page you referenced.

> I can’t find this narrow extension that you are referring to. Can you provide
> a link? In any case, extensions don’t cut it for corporate environments
> because they are far less likely to be maintained than core projects.

I’ve got it from the mailing list, but I unfortunately can’t locate it now. If you are interested, I can put it up on BB, as I have it on my machine now. I used it some time ago for a different use-case: checking out a Linux kernel on Windows (case-collisions).
You are right about extensions, though. But even core projects don’t guaranty maintenance. Especially if they are not used by the maintainers themselves, like subrepositories.

> Narrow clones would be even nicer but I don’t think we’re going to get that
> any time soon. It seems to have been discussed for most of Mercurial, Git,
> and Bazaar’s lives and it hasn’t happened yet. Git is the only one to get
> partial checkout support and it took years for a very simple implementation
> to appear. The interface still stinks too – I’d like to just run git checkout
> rather than editing a file in some obscure location and following up with a
> series of commands.

I don’t know… that extensions does a pretty good job in doing it transparently. I can see how a full narrow clone is not far away with it, given Mercurial’s file-based revlog store in contrast to Git’s object store. Obviously the pressure is not high enough on the maintainers of the three mentioned DVCS to implement such a feature. Although it really seems to be the only thing that Subversion can score as point against DVCS.

By Face on February 23, 2012

I was going to post a question and an answer on stackoverflow about using the convert extension to make partial clones for (a) answer your point about partial clones and (b) get some free upvotes but someone did it before me.

The convert extension is one of the mandatory tools to Mercurial users. One should know it well if intends/has to use Mercurial.

PS: I know the debate is mostly over here but I think this note can be useful for future readers arriving from Google.

Bruce, I’m not sure what your point is. “hg rm” is simply an alias for “hg remove”, and “svn rm” for “svn delete”. If “git rm” is so different, then it shouldn’t be shown as an “equivalent” in the table.

The point of the table in the article was to show that git uses different names for things, so there’s more effort in “retraining your fingers to type the new commands”, but in fact most hg and svn users already use the short aliases that their tools provide, which are exactly the same names as git uses.

By Alex on April 11, 2012

I don’t think it’s strictly fair to expound on Mercurial’s amazing alias and extension support in a “Mercurial vs. Git” post (due to the implication that git’s parodies of these features sucks). As a handful of examples:
– Git fully supports aliases defined in much the same way
– “git diff | curl …” to a paste service will work just as well as hgdiffpaste
– A cool but overlooked implementation detail of git is that all of the internal commands are implemented via “git-xx” scripts or binaries – so, “git diff-paste” could just as easily be implemented by a “git-diff-paste” script, which then looks and acts like it’s part of git proper.

Various other things that don’t really add up:
– git mv/rm as problems. mv and rm are standard coreutils utilities, and are the idiomatic way to rename and remove/unlink files. Far be it for me to claim that they’re better than ‘remove’, ‘rename’, and ‘delete’, but anybody who has even a modicum of experience working in a terminal (which they’d have to to hopefully write scripts to extend hg or git!) knows what mv/rm are used for and why they’re called such.

A Sane Command Line Interface
———-
I’m not sure what he’s talking about, when he claims that Git is more flexible. If you’re using the `alias` command, they are both just as flexible. And while Mercurial may follow the “Unix philosophy”, I’m not sure his table of commands really proves anything. For example:

hg commit ; hg push git commit -a ; git push

I don’t use `git commit -a`, I just use `git commit`, and let my system open up nano, and from my experience, it’s the same thing in Mercurial.

hg remove git rm
hg move/rename git mv

Doesn’t Unix also suggest using commands that make sense? Since when does *nix support `remove`?

And before someone says, “But it’s not just for linux!” take a look at a lot of of the other commands. `cat`, `diff`, `–update` all scream *nix to me.

hg pull –update git pull

How is this “clearer” than git? I feel that the author has contradicted himself here, as the git pull is simpler and clearer.

The only reason that the Git CLI seems more cluttered is because table is silly. He goes on to say that Git is different from what Subversion users would expect. SVN is an entirely different animal. Git and Mercurial are a new type of software development tool that are way beyond what Subversion is. If you’re using Subversion or CVS, you’re only putting your team at a distinct disadvantage. To be honest, I don’t even know why he even puts Subversion up on the same bar as Mercurial or Git.

Safer History with Mercurial
———-
Just because Mercurial doesn’t supply a mechanism to screw with your history, doesn’t make it better. In fact, although I would advise anyone with a keyboard to not screw with the history, but one should still be supplied tools to do it, if not for some extraneous reason.

Backwards Compatibility
———-
The linux team is focused on backwards compatibility. There are a crazy number of packages released open source, most of them [need to be backwards compatible](http://packages.ubuntu.com/oneiric/allpackages). Considering linux is a core proponent of Git, I have no idea how Mercurial is more backwards compatible than Git.

Easy to Extend
———-
The code given looks like a `.bashrc` file. How can hg not be replaced with git in this instance, and loaded into the shell? To add to this conversation, some people talk about how the API is better than git. Is this what you’re talking about?

svn/hg/git all support mv and rm with the same semantics – and mv and rm are more “elegant” by the author’s standards as they match the unix commands that manipulate the fs in the same way as the VCS commands are manipulating the repository.

git also supports shell aliases.

There are good reasons to choose mercurial. Windows support. If you’re a python shop, it’s really easy to extend and add support for bug tracking, testing, automated builds, etc. The git revert/reset/checkout thing can be confusing for those of us used to older VCSs. The CLI is one char shorter to type.

But most of this article reads like someone who has made their decision based on incomplete information and is hunting around for reasons to support their bias.

By Kevin Lyda on February 23, 2012

Not a fan of this comparison for a few reasons.

– You say ‘sane command line interface’, which would be a valid point to make as git can be fairly esoteric at times, but then you back up it up by saying Mercurial is “closer to svn”. I’ve never been a subversion user, but even if I was: being similar to existing tools doesn’t make things sane, just similar. If I write a new language borrowing heavily from Perl, I doubt it would be called “Sane”.

– Safer history. I can sympathize with this point, though another way of wording it is “Mercurial is more limited and less flexible”. Yes, power can be dangerous, but it’s hard to say that Mercurial is more powerful, at least in this regard — though on the other hand, it is safer.

– GUI and Windows. With you all the way here, except … git is primarily targeted at / developer for Linux users. “Real engineers use the commandline”. So, yo’ure definitely right here, except I’d probably just say that Mercurial is more accessible those not comfortable on the commandline.

– Backwards compatibility. This isn’t a git problem at all, but by talking about Mercurial here, you imply it is. This one is 100% not appropriate.

– Hosting tools and services. Sure, Mercurial might have a webserver built in, and i get you want to self-plug here, but git has Github which definitely deserves a big mention.

Overall, this is super one-sided. There are a couple of good points buried in here, but other points repeatedly destroy any credibility here. My takeaway from reading this is that Mercurial is the less powerful of the two products, but more suited to an enterprise environment with inconsistent training or low hiring standards e.g. somewhere some “kid” can get a hold of the repository and `git push origin :master` (what with commercial support, better windows and GUI support, etc). There’s a big market for that, and having a tool for that kind of environment is great, but don’t try and tell me your safety scissors are better than my Ginsu knife pointing to your stylish blue handle.

If you want to write blog post on what Mercurial has to offer over Git for people who work in Linux, know and learn their tools well, and don’t let “just anybody” get access to their repository, I’d love to read it. And I would seriously consider moving to Mercurial if someone could make a good case for it over git. So far, no one has.

By John Hinnegan on February 23, 2012

There seem to be a lot of Git defenders among the commenters. I hope there is no unspoken “real programmers only use Git because Linus wrote it” sentiment behind this. I believe in the KISS principle in my development tools. I’d rather spend my time writing software instead of figuring out the tool. Git’s complexity was an immediate turn-off for me. For me Mercurial requires less time in feature discovery and self-education time. I also regularly switch between GUI and CLI use of Mercurial. And I absolutely love that “hg serve” starts a special purpose web server for discovering and exploring the state of the code.

“There seem to be a lot of Git defenders among the commenters. I hope there is no unspoken “real programmers only use Git because Linus wrote it” sentiment behind this.”

Everytime you make a passive-aggressive ad homenim attack, Cthulu punches a unicorn.

By Kevin Lyda on February 23, 2012

This. Also, the power and complexity of git isn’t merely extra work for me, it’s extra risk for my team in the form of team members not fully understanding all the interactions the various commands have with each other. With git, it’s my understanding that’s it’s possible for someone to rebase their repository in such a way that it makes the history a nightmare for those who pull from them. Sure, we could adopt a “gatekeeper” approach like the Linux kernel team has, but I’d rather just not have the worry in the first place, especially for small, high-trust teams. When a team’s development needs grow to the point where the power of git is useful, then there will also be (or, there had _better_ be) enough institutional knowledge and processes to help manage that power. Without having read anything, I suspect this was the source of the “Mercurial for small, git for large” advice.

Personally, I prefer Hg over Git; but I feel the argumentation in this article was poor. Talking about extremely simple shell aliases that would work the same in Git? Really?

My reasons:
– Hg command-line is clean and simple, easy to learn, easy to remember. Git feels messy and confusing.
– Hg command-line output is concise, very similar to other Unix tools. Git commands output lots of extra messages that we learn to ignore over time.
– Hg help is extremely useful. If I want to learn something, I can find easily and in a very concise way using hg help. In git, it just opens the verbose manpage.
– I needed to work with people running Linux, Mac and Windows. Considering the cross-platform support of Mercurial, that was my choice.
– Hg GUIs were a bit lacking in the past, but now I can say TortoiseHg is simple to use and works very well. I’ve yet to find a good git gui (I’m using gitk for now).
– I’ve installed a few mercurial plugins to add some nice features (and even mercurial already comes with a few plugins). It is very easy to extend mercurial features, I’m not sure about this in Git.

In the end, I completely agree with Jack Holt’s comment: “I’d rather spend my time writing software instead of figuring out the tool.” And for this reason I like mercurial: it is easier to use and each command does what I would expect.

My advice after having used git on a daily basis for a couple years:
* Don’t use “git rebase –interactive” unless you know what you are doing. You probably don’t know what you are doing, and all you are doing is breaking “git bisect”.
* Never use “git push origin –force”. Like rebasing, it wasn’t written for you, it breaks bisect, and it can render your previously working codebase into an unrecoverable mess (nevermind mess up pulls, merges, etc.).

Other than that, git works great. Mercurial works great too. But this article wasn’t a comparison.

By Josiah C. on February 23, 2012

>>”Using mercurial can be dangerous”

What a FUD…
one: It’s DVCS for source code, not backups, binary or other stuff!
two: very bad workflow
three: of course, because it’s the “Destructive command”!

By Anonymous on March 13, 2012

This article was a disappointment to me. It doesn’t show a single strong argument for prefering Hg over Git and it tries to pigback on myths and misconceptions carried over from ancient times.

I think Git is better overall, but Hg is good enough. Tool for tool I’d chose Git anytime. Unless I have strong Python skills and are willing to extend the tool. Or if I’m going to participate in a project already using Hg.

The comparison given did not convince me either way. I think that at this point in time the non-functional aspects of hg or git are perhaps more important.

As projects, which has more active developers improving it and how many users are there. This will drive more features and quality. Also, which one has a “better’ architecture that can grow to meet ongoing needs, such as binary file support, and adherence to evolving standards.

Comparing the interface while important, is not critical. That would be like comparing Editors or Shells. They all can do editor and shell stuff, well old MS-DOS can’t, but where they can’t there are ways around it.

Btw, I use Git as ad-hoc DVCS to an SVN corporate system. Many developers don’t even know how to open a command shell.

The blog post of a guide to branching in mercurial is informative, like saying coffee comes from the Coffea plant; it doesn’t tell you anything about whether it’s good or bad.

Anonymous branches are not useful, and anyway can be implemented in git by naming the branches anonymous-$x. Multiple heads are stupid, the same can be achieved with remote tracking branches when a push fails because a new head was created. Named branches provide no advantage whatsoever; I’ve shown all the use-cases where they are used to achieve something can be achieved in a different way with Git. And finally, bookmarks don’t have remote namespaces, so they can easily conflict, and you can’t easily remove them, and/or push them if your team has a policy of no-multiple-heads.

So yeah, Git’s branching model is superior, not because a “git fun-boy” says so, because they objectively are. The facts show it. Period.

I am just annoyed that I have to learn and use two distributed version control systems that are similar but just different enough to require almost complete re-learning when going form git to hg. Once you have learned git well what use is hg?

Mercurial just works! And is at least twice simplier to lear. Git is good only for people who want to solve issues with Git instead of real programming. In advance Git support for Windows is a real shame! Thats next reason you shouldn’t use it in your company.
Mercurial is trully multiplatform – much simplier, which is very important when there is sombody new (becouse you want to learn him issues about your project and not about Version control system)
Git is good just for hacking, but in real world it slow you down.
Please, people wake up and USE MERCURIAL!!!

I tried git for a GIS project I use where code and data are mixed, but it kept choking on large binary files that needed to be in the repo (they’re core data for the software, and it needed to be versioned too). Mercurial just tromped right on through it and versions it just fine. I see good reasons to use git, but for me Hg meets my needs (plus, TortoiseHg is far better than mysisgit, IMO).

Last time I checked, Mercurial does not support unicode characters properly. It treats files with unicode (UTF-16) as binary. SVN and GIT recognize unicode as text, and are able to compare differences.

They do essentially the same. Commands, functionality, SHA1, change-sets, commits, merges, underlying design and ideas, all are very similar in concept, it seems like if you know one, the other is trivial to switch to, yet git is literally 1 order of magnitude more complex:

There’s also HgLab ( http://hglabhq.com ) – a source control management system for and Mercurial Server for Windows with push, pull and streaming capabilities, repository browser, Active Directory integration, ACLs and lots of other things.

While I can appreciate seeing points about Mercurial’s third party commercial support in an Atlassian blog post, the section implying that Mercurial is more extensible than git reads like a canard to me. One of git’s fundamental design features is that all its internals are fully exposed as shell commands (it’s well known that many of the `porcelain’ commands like checkout and merge were originally implemented as shell scripts). The shell interface is the basis of many contemporary third-party tools (see: OpenStack’s git-review, git-stitch-repo, the original git-subtree, etc).

As for backwards compatibility – statements about Matt Mackall in support of Mercurial carry about the same weight that attestations to Linus Torvald’s famously hard line position on ABI compatibility do in support of git (e.g. not much). The git repo format and network transport protocol have been stable for many years now. git is being successfully used by many high-profile projects. A source control system that’s good enough for million dollar projects like Android or the Linux kernel isn’t going anywhere overnight.