Shortcomings of Mercurial

Mercurial is, by far, the best revision control application I’ve ever used, with Git a close second. Fundamentally, Mercurial does revision control correctly: distributed, clean CLI, and good documentation. I’ve never had any qualms with it, even in team settings. On the other hand, I have noted some complaints teammates have had with Mercurial, sometimes complaints causing them to stop using Mercurial or DRCSs all together.

  1. Mercurial doesn’t maintain file and folder permissions. This becomes a problem when hosting a shared Hg repository on a machine without root access. Other group members add files to the shared repo via ssh and it’s up to the users umask to set file permissions. This means I may have files in my home directory which I can’t access.1
  2. Merging tools and file servers on Windows are lacking. Windows users expect the revision control to supply these tools. Unix users (including Mac OS X) are used to having file servers and merge tools supplied by the distribution of the operating system, not the revision control application. Some Windows users want GUIs like TortoiseSVN.2
  3. Binaries are handled terribly. Mercurial currently doesn’t good way to handle binaries. For instance, if a binary (such as an image) is moved, it’s considered a new binary. Keeping many binaries in revision control and moving them a lot will make the repo huge.

Aside from binary handling issue, I think the reason these “shortcomings” have never bothered me before is because I consider the file permissions to be a part of the operating system and the merge and server tools to be separate applications. Mercurial, thought easier to use with said external tool, is just as functional without and I will continue to use it as my main development tool.

  1. When I asked about the file permission problems on the Mercurial mailing list, the Mercurial maintainer responded with this:

    Patches to inherit permissions from “.hg” are now in the crew repo which
    will get merged into mainline shortly and show up in the 1.0 release
    very soon.

    In the meantime, you’ll have to beat people into setting their umask
    — Matt Mackall


  2. TortoiseHg is now available for Mercurial. []
    None Found
  • Jakub Narebski

    A bit of Git advocacy:

    * Git handles binary files correctly (it detect binariness using algorithm used by diff and other GNU tools, but you can mark given file as binary or text using gitattributes). Binariness of file does not matter to the Git libXdiff deltaification. Git can send / generate binary patches. Unfortunately, depending on binary file and how much it repesentation change due to small underlying change, Git can fail to detect file rename or file copying (it is based on similarity score).

    * From some time Git ships with its own diff3 / rcsmerge file level merge tool. It would put CVS-like conflict markers in a file which has merge conflict. There is git-mergetool helper which helps to use configured graphical merge tool kile KDiff3, Meld, Emacs emerge etc.

    * Git has core.sharedRepository configuration option, with possible values being: group, all. umask, to set correct permissions for git repository files, when using repository in shared fashion. Nevertheless DSCMs are usually geared to other workflows…

  • Luke Hoersten

    Your absolutely right. I love Git and, like I said, it’s a damn close second for me. When trying to get my teammates to use Git, they almost all used it incorrectly because they could never figure out what commands to use. Git has the uncanny ability to allow users to think they are using it correctly when in fact they are breaking things.

    Mercurial also has the merge helper like Git but I was talking more about GUI merge tools. As far as I know, Git doesn’t come default with a graphical merge tool like Meld. I should have been more clear about that.

    Anyway, thanks for filling in the Git side of the post! I love accurate comments.

  • William Tanksley Jr

    Regarding merging tools on Windows: I installed the distro from, and it comes with all required tools. I didn’t even know there was a bare-bones distro, although I knew it was possible to configure.

  • William Tanksley Jr

    I have a question for a git guru.

    Git looks really cool; I just found a Windows (mingw) port, so I’m happily working with it. It seems very slow, but I’m sure that’ll go away with time. I love git-svn.

    The question: is it possible to disable git’s insertion of merge markers? I really like how Mercurial never alters a file; when a merge is needed, it’s treated as a basic attribute of the repository, not a local problem in a file. This means it’s NEVER possible to accidentally leave merge markers in a file (something I’ve had happen on several different CVS-using projects).

  • Luke Hoersten

    Good Find. Looks like that’s new since February 25th:

    “2008-02-25: Mercurial 0.9.5-434139080ed4 – Version 0.9.5 + fixes through 2008-02-25.

    NOTE: This version includes the new standard merge logic that tries to detect appropriate merge tools. I’ve enabled the sections from contrib/mergetools.hgrc in the default Mercurial.ini that the installer writes. See hgrc.5.html in the Docs subdirectory for more information on the syntax.”

    Out of curiosity, what merge tool does Hg ship with on Windows? These comments look like it Hg will only try and detect what’s already installed.

  • Jason Kratz

    Windows users have TortoiseHg which is being worked on.

  • Jason

    TortoiseSVN uses should check out TortoiseHg (

  • Luke Hoersten

    This is great for Hg! Looks like they are aiming to support Gnome/Nautilus on Linux as well. Thanks for finding this.

  • Jakub Narebski

    @William Tanksley Jr:

    First, when there is a merge conflict, Git leaves all three versions (base / ancestor, ours, theirs) in the index (commit staging area), and stores file with merge markers on filesystem. So you always have easy access (“git show :1:<file>” for example to get base version) to all versions.

    Second, default pre-commit hook which ships with Git, and is by default installed in newly created repositories, detect merge markers in file (and also things like trailing whitespace) and refuses to make a commit if it looks like you didn’t resolve a merge. You just have to enable it by making it executable (“chmod a+x .git/hooks/pre-commit”). Of course you can foce skipping verification phase if the tool misdetected merge markers with –no-verify option.

    Third, you can use gitattributes to set merge driver for specified files, for example for all files, or/and you can use merge.default configuration option, choosing e.g. “binary” driver which leaves current version of file in the working dir in the case of conflicts.

    BTW. why didn’t you ask this question on Git mailing list or on #git channel on FreeNode? Git mailing list is open; you don’t have to subscribe to post. Just make sure to specify that you’d like to get messages replied also to you, and/or read mailing list via mailing list archives or GMane NNTP (Usenet, news) interface.

  • Alex Popescu (the_mindstorm)

    The only small problem I have with git is that it requires so many dependencies to get installed. Macports is something like 10+ including perl, etc. I am not sure why all these are needed, but so far I haven’t been able to get it working. Not to mention that if you’d like to use the git-svn part that will raise the number of dependencies close to 30. Mercurial hasn’t required me to install anything except a decent Python version.



    .w( the_mindstorm )p.

  • Luke Hoersten

    These may seem like minor hurtles but this is what I was trying to convey with my post. These little things add up and can cause great projects not to work for technical reasons =/ It’s unfortunate that more people aren’t willing to sacrifice but I guess they don’t see the value.

  • Jakub Narebski see section “Portability” (Git on MacOS X).

    As to why Git has so many dependencies: much of commands are written in either Perl (thus requiring Perl), or in shell scrips (thus requiring some of shell utils). Git also uses existing libraries, like libz, or libcurl, or libcrypto for things like compression, or HTTP protocol, or cryptographic hashes.

    By the way, if I remember correctly, Mercurial has some of its code written in C for performance. And you have to got all those Python modules installed.

  • William Tanksley Jr

    I’m not on my Mercurial computer, so I don’t know what it ships with. The feature you’re listing is a new feature of the core Mercurial, and doesn’t describe the berkwood package. That one actually does come with all the graphical tools I’ve been able to ask for (i.e. everything seems to work out of the box; I’ve even played around installing tons of different plugins).

  • William Tanksley Jr

    I’m glad to hear git doesn’t try to be clever and detect the merge markers. I’ll hold off until I figure out a way to get it to not insert the markers in the first place.

    I think I found the mailing list at….

  • Jakub Narebski

    @ William Tanksley Jr:

    Errr… I think I haven’t been clear enough. With Git you can either detect merge markers in (default, you only need to enable it) pre-commit hook and refusing commit unless overriden with –no-verify.

    Or you can change default file-level merge driver for some files or for all files (using combination of gitattributes and config) from “text” (which inserts diff3 -E like merge markers) to “binary” (which leaves ‘our’ version on disk and does not insert any merge markers).


  • Regis

    I have never really used Hg, but when I read the issues you point out, I wonder what makes it better than svn.

  • Luke Hoersten

    This article has links to the videos that showed me why DRVSs are better. Let me know if you still don’t see after reading that article.

  • Bryan O’Sullivan

    For a GUI, you’ll want to use TortoiseHg. By the way, your blog doesn’t seem to put dates on your postings, so I’ve no idea whether you wrote this yesterday or a year ago.

  • Luke

    It’s over there on the right, but it took me a while to find it too, and it would be much better if it was nearer the title of the post.

  • Luke Hoersten

    Yeah sorry about that. I didn’t design the theme but I have to say, for most cases I’d prefer it over there on the side. I respect the designer and his design decisions.

  • Luke Hoersten

    So now that 1.0 has been released, I haven’t checked but I’m assuming the file permissions problem has been fixed. And TortoiseHg solves the GUI problem for Windows users. But what about the way binaries are handled? Especially if my group loves to move and rename binaries in revision control? This, in my mind, is the final hurtle for Hg being used without hesitation.

  • Jakub Narebski

    Git pack files uses binary xdiff for deltaifying, so having many large binary files and moving them around shouldn’t be the problem. On the other hand Git does not track renames, but does similarity estimate based rename detection, so if representation of binaries changes much (e.g. encrypted files) you are out of luck…

  • Jakub Narebski

    Ooops… sorry for repeating myself.

  • julian3

    Hi guy, thank you very much for the topics shortcomings of Mercurial. However, If you feel bore, pl take a look of gochi juice , new item of goji berry’s which increased energy, sharper mental acuity, less fatigue, improve athletic performance, better quality of sleep, easier to woke up, bowler regularity, felling calmer, healthier, happier, reduction of stress and many more. The clinical trial has proven that drinking just 4 ounces a day can have significant positive benefits in 19 areas of your health and well being after just 30 days. You're going to love GoChi!

  • Martin

    Better rename handling is currently being worked on in Google Summer of Code 2009:

  • Martin

    Better rename handling is currently being worked on in Google Summer of Code 2009: