When looking at comparisons, it seems to me that there could be a 1:1 mapping between their feature sets. Yet, an often cited statement is that "Mercurial is easier". What is the basis of this statement? (if any)

  • 21
    Weird, I never heard Mercurial was easier. I found more documentation for Git (may have been perception) so I learned that.
    – Nic
    Jun 26, 2011 at 23:54
  • 16
    Because it was made by Linus?
    – Job
    Jun 27, 2011 at 1:43
  • 124
    Veering into holy war territory here, but I found Mercurial easier to use than Git because, as a Windows user, I felt welcomed by Mercurial, and treated like a freak and a loser by Git. I know I'm anthropomorphizing software, and I know that both are perfectly capable of being used just fine under Windows, but that's the impression given off by the two of them. Jun 27, 2011 at 1:56
  • 24
    – Svish
    Jun 27, 2011 at 8:36
  • 11
    I wonder how many people would be using Git if Github didn't exist, or didn't have so many high-profile projects on it?
    – Chris S
    Jun 27, 2011 at 13:16

9 Answers 9


Case in point: Lets say that you want to change the username on all your previous commits. I've needed to do this several times for various reason.

Git Version

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
                git commit-tree "$@";
        fi' HEAD

Mercurial Version:

authors.convert.list file:


Command line:

hg convert --authors authors.convert.list SOURCE DEST

Now, which one looks easier to use?

Note: I spent 2 years working solely with Git, so this isn't a "I hate it, I didn't get it in 2 seconds" rant.

For me, it's the usability. Git is very linux oriented with a linux way of doing things. That means command line, man pages, and figuring it out for yourself. It had a very poor GUI (note: I'm basing this off of msysGit from about a year ago), that seemed to just get in my way. I could barely use it

The command line was worse. Being a Linux oriented program, on Windows it was very difficult to use. Instead of a native port they simply wrapped git with MinGW (Think cygwin), which made working with it much more difficult. MinGW isn't Windows Command Prompt, and just acts different. It's crazy that this is the only way to work with Git. Even in Linux it seemed the only way was to work with straight command line. Projects like RabbitVCS helped some, but weren't very powerful.

The command line oriented approach and being a linux program meant that almost all the howto guides, help documentation, and forum/QA questions relied on running monstrous commands like above. The basic SCM commands (commit, pull, push) aren't as complex, but any more and complexity grows exponentially.

I also hate the one place that lots of OSS git users seem to hang around: Github. When you first go to a github page, it slams you with everything you can possibly do. To me, a projects git page looks chaotic, scary, and overly powerful. Even the explanation of what the project is, is pushed down to the bottom. Github really hurts people who don't have a full website already setup. Its issue tracker is also terrible and confusing. Feature overload.

Git users also seemed to be very cult like. Git users seem to always be the ones starting "holy wars" over which DVCS is better, which then forces Mercurial users to defend themselves. Sites like http://whygitisbetterthanx.com/ show arrogance and an almost "Use my software or die" mentality. Many times I've gone into various places of help only to be flamed for not knowing X, using X beforehand, using Windows, etc. It's crazy.

Mercurial on the other hand seems to go towards the kinder approach. Their own home page seems much more friendly to new users than Git's. In a simple Google search the 5th result is TortoiseHg, a very nice GUI for Mercurial. Their entire approach seems to be simplicity first, power later.

With Mercurial I don't have SSH nonsense (SSH is hell on Windows), I don't have stupidly complex commands, I don't have a cult user following, I don't have craziness. Mercurial just works.

TortoiseHg provides an actually usable interface (although lately it seems to be growing) that provides actually useful features. Options are limited to what you need, removing clutter and options that are rarely used. It also provides many decent defaults

Mercurial, being very friendly to new comers, was very easy to pick up. Even some of the more complex topics like the different branching model and history editing were very easy to follow. I picked up Mercurial quickly and painlessly.

Mercurial also just works the first time with little setup. On ANY OS I can just install TortoiseHg and get all the features I want (mainly context menu commands) without having to hunt for different Guis. Also missing is setting up SSH (half of the guides out there say to use Putty, Plink, and Pagent while the other half says to use ssh-keygen). For new users, TortoiseHg takes minutes to setup while Git takes 30 minutes to an hour with lots of googling.

Lastly you have the online repos. Githubs equivalent is BitBucket, which has some of the issues I outlined above. However there's also Google Code. When I go to a Google Code project, I don't get feature overload, I get a nice clean interface. Google Code is more of a online repo/website combo, which really helps OSS projects who don't have an existing site setup. I would feel very comfortable using Google Code as my projects website for quite some time, only building a website when absolutely necessary. Its issue tracker is also powerful, fitting nicely in between Github's almost useless Issue Tracker and Bugzilla's monstrosity.

Mercurial just works, first time, every time. Git gets in my way and only angers me the more I use it.

  • 6
    Commenters: comments are meant for seeking clarification, not for extended discussion. If you have a solution, leave an answer. If your solution is already posted, please upvote it. If you'd like to discuss this question with others, please use chat. See the FAQ for more information.
    – user8
    Jun 30, 2011 at 0:27
  • 1
    IntelliJ IDEA and Xcode 4 have wonderful integration with Git on their respective platforms and for day to day tasks you never have to use the command line.
    – user7519
    Sep 19, 2011 at 1:06
  • 4
    I would like to add that tortoiseGIT is a lot better now when you want to use GIT on windows. You still have to deal with the SSL keys and the installation process is not smooth, but when done it works easily.
    – Arkh
    Oct 1, 2011 at 22:14
  • 2
    Git Extensions I personally find much easier to navigate and work with than TortoiseHG on windows, and I have only used 1 command line ever with git.
    – KallDrexx
    Nov 18, 2011 at 18:26
  • 1
    I'm sort of baffled by this line: "MinGW isn't Windows Command Prompt, and just acts different. It's crazy that this is the only way to work with Git." I use the msysgit installation and option 2, to run from the Windows command line. It works fine. There are a few things that don't work (like the caret, a line-continuation character in DOS) but there are alternatives to those (like the tilde) that work fine. I'm not a command-line enthusiast (or at least I wasn't before I started learning Git) but using Git with the command line is really easy. Am I missing something?
    – Kyralessa
    Feb 19, 2013 at 21:05

Git versus Mercurial

Mercurial is generally believed to be simpler and easier to learn than Git. In turn, there is often the perception that Git is more flexible and powerful. This is due, in part, because Git tends to provide more low-level commands, but also in part because the default Mercurial tends to hide advanced features, leaving it to users to edit the mercurial config file to activate the advanced features they like. This often leads to the perception that advanced features are not available in Mercurial.

Git Concepts

Mercurial has always focused more on interface aspects, which made it originally easier to learn. In comparison to Git, a shallower understanding is required to operate with Mercurial in a useful manner. In the long run, such encapsulation has given Mercurial the false appearance of being less powerful and featureful than it really is.

  • 73
    So Mercurial hides only the advanced functionality, while GIT hides all functionality ... ;-)
    – awe
    Jun 27, 2011 at 8:56
  • 4
    Git does have more power. For example there is no equivalent to git's HEAD~1. Mercurial has p(x) which spans across branches, how useless. There is no stage in Hg. All branches must be pushed when you push. Mercurial is just not as flexible, even with all the plugins like histedit, shelf and rebase. Git's command line is also better, it gives the user hints, mercurials does not. I am forced to use this slightly crippled DVCS at work and I have come into situations where mercurial lacks the power to do what I want.
    – Benbob
    Jun 28, 2011 at 5:09
  • 22
    @Keyo: Mercurial has ~, see revsets. It doesn't have a staging area, but you can emulate it with MQ, which is so much more powerful. Learn to use the tool rather than sticking to what you know from git, it'll pay off.
    – Idan K
    Jun 28, 2011 at 6:50
  • 22
    @Keyo: You don't have to push all branches with Mercurial when you push. You can push a specific branch (hg push --branch BRANCH) or up to a specific revision (hg push --rev REV). Please see hg help push for more options.
    – Regent
    Jun 28, 2011 at 8:46
  • 1
    FYI, one can get a considerable subset of the staging area using the record extension. OTOH, I think the shelve extension (modelled after the "shelve" command from Baazar, and close to "git stash") serves much better most of the purposes of using the staging area.
    – brandizzi
    Jun 30, 2012 at 0:00

Context: I use both Mercurial (for work) and Git (for side projects and open source) on a daily basis. I primarily use text-based tools with both (not IDEs) and I am on a Mac.

In general, I find Mercurial easier to work with. A few things that I find make Mercurial easier:

  1. Lack of the index. The index is a powerful tool enabling many of Git's features but it's also an extra layer that adds a step into many things I do regularly. Mercurial's workflow is more similar to something like svn.
  2. Revision numbers instead of shas. This is a small thing that I find makes working with every day commands a lot easier in Mercurial. It's way easier to push a few revision numbers into your head during a rebase, merge, etc while writing a command than to do the same with even shortened shas.
  3. Branches. Git's approach to branches by naming commits is powerful and substantially different than other version control systems. It makes certain things a lot easier. I find that Mercurial's approach matches svn thinking a bit better and makes it easier to visually understand the branch history. This may just be a preference.
  • 6
    +1 for mentioning the index; I think the index and its interactions are the thing that makes git more difficult to learn than mercurial. Jun 27, 2011 at 18:56
  • 18
    The hg equivalent to git branches are actually called bookmarks. As far as I know, hg branches don't have an equivalent in git.
    – Hank Gay
    Jun 27, 2011 at 19:10
  • 6
    I'm in the same situation, with mercurial at work and git at home. Mercurial branching is rather annoying to me, I like to have private branches and push them when I like. Mercurial forces me to use shelves or additional repos. Revision numbers are silly, give me the hash. The stage is great in git, I miss this. I'm really missing the power of git. I did around a few things with some plugins but the branching really annoys me.
    – Benbob
    Jun 28, 2011 at 4:57
  • 6
    @Keyo - In my experience, git branching is a subset of hg branching. In hg you can have both named and unnamed (topological) branches, and can even manage unnamed branches in the same way as git using bookmarks. I've never really seen the point in the staging area. I would much rather shelve unwanted changes and then make sure that my code compiles & completes my tests before committing it. I can then un-shelve and continue. Also, Charles Bailey's "Massaging Hunks" (p90+) scares me *8') : accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
    – Mark Booth
    Jun 29, 2011 at 10:27
  • 7
    @Keyo: In Mercurial, private branches are called 'bookmarks': update to the root revision, hg bookmark keyo-stuff, do things, hg commit, then eventually hg push -B keyo-stuff. If you don't like revision numbers, don't use them; Mercurial will accept a hash anywhere it will accept a revision number, i think. I have to say, your comments bashing Mercurial for a lack of features it does in fact have come across as ignorant and a little aggressive; you are not doing a lot of good for the stereotype of Git users! Jul 3, 2011 at 15:02

This is very subjective and depends from one person to another, but yes, I would go that to someone completely new to VCS or someone coming from one of the "old school" VCSs, Mercurial will seem easier.

For example, adding files, the non-existence of the index in Hg, the ease of going back to some old revision and branching from there (just update and commit) as some of the most "obvious" examples. Now most of features of one system can be emulated in another and vice versa, but that requires some knowledge in Git, while in Mercurial the defaults (if you'll allow me to call them that) are rather "user friendly". Those little things - the switch here and there, the non-obvious behaviour in one command and so on ... these things add up, and in the end, one system seems more easy to use than the other.

Just to make the answer complete; I use git, but when recommending a VCS for someone who's "new to them", I almost always recommend Mercurial. I remember, when it first came into my hands, it felt very intuitive. It is my experience that Mercurial produces less wtf/minute than Git.

  • +1 for "less wtf/minute" -1 for "this is very subjective". It's not very subjective... I don't know why people still think differences of UI are subjective. If I take mercurial and md5 hash its commands, you wouldn't make the argument that some people might find an md5 hash more intuitive than the original, would you? (I hope not). The same is true of Git. Git is only easier than mercurial if your experience with git is considerably more substantial than mercurial.
    – weberc2
    Sep 21, 2013 at 17:35

I think it's as simple as this: Mercurial has a more familiar syntax (particularly for SVN users) and is fairly well documented. Once you get used to the Git syntax, you'll find it as easy to use as anything else.

  • 7
    Nope. There are too many more workflow steps for you to call it just "different syntax". You have to understand the underlying model you are manipulating, and all the state of the git index, in order to use Git. Saying SQL and Pascal are two different syntaxes for the same thing would be equally wrong. Git is a file-system-content-versioning system with DVCS features. Mercurial is a DVCS that does not do every file-system-content-versioning operation GIT does, only the subset that DVCS users all require.
    – Warren P
    Nov 20, 2012 at 19:55

Perceptions might be changing over time, on this. Mercurial is very well designed, and so is Git. Mercurial seems to be easier to learn (at least it was for me), and there have been difficulties that I encountered in Git, that I have no parallel for in Mercurial. I tried to learn Python, and Ruby, and got farther, faster with Python. That doesn't mean Python is always and everywhere better than Ruby, or even that it's better for me. It's just what I learned and stuck with. Programmers often make holy wars out of personal preference. Other human beings do that too.

I am a mercurial user who tries to keep an open mind about Git, and I freely admit that it hasn't "become my new favorite thing" to the same extent as Mercurial has. I think Git is really really nice though.

A counter example for GIT/mercurial complexity: Nice GIT support is built into XCode, on Mac. Less easy to use XCode with Mercurial than GIT.

My experience with GIT so far has been that I get confused and lost and need to go consult the documentation more while using it. I believe that a lot of documentation has been written, but nothing that has enabled me to "grok" it. Secondly, I can modify and extend Mercurial easily in Python, and as I am adept in Python, and as anyone really could learn python quickly, it seems an advantage to me. I also know C, and write Python extensions in C, so I suppose some day, if I needed one, I could easily write a Git extension in C.

Ease-of-use is not something that is easy to quantify. It's there, and I don't think it's entirely subjective, but we don't have good objective measurement techniques. What would the units for ease-of-use be? Milli-iPods?

I am not so partisan as to be 100% pro-mercurial, and 100% anti-git. I'm more comfortable on Mercurial right now, on Windows and on Linux, and when I start doing more Mac work, I expect that I'll try to stick with XCode+GIT.

Update 2013: I have now used Mercurial AND GIT long enough to find some features that I wish it had that Git has, such as this question about merge strategies. Really Git is amazing, if difficult to learn, and sometimes maddeningly complex.


There are a few things that IMO are likely to put new users off Git:

  1. The Git culture is more command-line centric. While both tools do tend to focus too much on the command line (as I've said several times, command line instructions may be powerful and more fluent, but they are not a good marketing strategy) this is much more the case with Git. Whereas Mercurial has a de facto standard GUI tool in TortoiseHg, which is even the default download option for Windows users on the Mercurial homepage, Git has several competing GUI front ends (TortoiseGit, Git Extensions, gitk, etc) which aren't well advertised on the Git website, and which are all a complete eyesore anyway. (Black text on red labels? C'mon, TortoiseGit, you can do better than that!) There's also a much more pervasive attitude in the Git community that people who use GUI tools are not proper software developers.

  2. Git has several out-of-the-box defaults that make perfect sense to advanced users, but are likely to be surprising if not intimidating to new users. For instance, it is much more aggressive about automating tasks such as merging (for example, git pull automatically merges and commits where possible). There is a case for fully automated merges, but most inexperienced users are terrified of merging, and need to be given the opportunity to gain confidence in their tools before unleashing their full power on their source code.

  3. Documentation and inherent complexity:

    $ hg help log | wc -l
    $ git help log | wc -l
  • 3
    Actually, I prefer a help that is 912 lines long to a help that is 64.
    – Dysaster
    Oct 1, 2011 at 21:15
  • 10
    Actually, I prefer a UI that is so intuitive and seamless that you don't need a help in the first place.
    – jammycakes
    Oct 1, 2011 at 21:40
  • 2
    I want both the GUI and the help. :) What seems intuitive to me is a mess for someone else.
    – Dysaster
    Oct 1, 2011 at 21:47
  • 1
    Sure, but when help is necessary, it should be easy to follow.
    – jammycakes
    Oct 1, 2011 at 22:42
  • 3
    I have thought of a new analogy; Git is like C++ (sorry Linus!) and Mercurial is like Pascal. What is implicit and can only be done one way in Pascal (or Mercurial) can be done explicitly, nineteen different ways in C++ (and Git). Some people prefer powertools with more buttons and levers, and Git is that.
    – Warren P
    Jun 6, 2013 at 12:50

One thing I can think of is

git add .
git commit -am "message"


hg ci -Am "message"

git commit -a doesn't add newly created files, hg ci -A does, which means that something that requires two commands with git can be done with one command in Mercurial. Then again, "less typing" doesn't necessarily mean "more user friendly".

  • 11
    I often find that in my workflow, automatically adding new files is actually undesirable. I've come to prefer how git commit -a works simply because it makes it easier to control what does and doesn't get added for a given commit. (It's actually not unusual for me to specify individual pathnames for every svn ci to avoid adding unrelated material to a commit.)
    – greyfade
    Jun 27, 2011 at 16:30
  • 3
    Fair enough, but I believe that hg ci without the -A flag does the equivalent of git commit -a. I've used git a lot more than hg, so I'm not 100% sure.
    – Zhehao Mao
    Jun 27, 2011 at 17:10
  • I've checked, hg ci == git commit -a.
    – Zhehao Mao
    Jun 27, 2011 at 17:19
  • but if you specify specific files with hg commit, you can avoid pulling in ones you don't want. In the infrequent cases where I want this control, I find this works well. Jun 27, 2011 at 17:33
  • 1
    why would you "git add ." and then "git commit -am"? Wouldn't everything already be added to the index?
    – jacobangel
    Jun 27, 2011 at 18:42

Because it is.

Git exposes far more of it's guts than mercurial. You can happily use mercurial within a few minutes of picking it up but I find git still very hard to grapple with after a couple of months of wrestling with it (I have done very little over the last couple of months other than try to learn git). I am using both from the command line and mostly on Linux so this is not just an aversion to the command line interface.

One simple example is the relatively few flags and command line arguments needed for mercurial compared to git. The staging area and the behavior of the add command in git also adds more complexity than is necessary. The trio of reset, checkout and revert and their multiple permutations adds enormous complexity, which was quite unnecessary when you witness the straightforward nature of revert and update on mercurial.

I agree with the above comment also about Hginit, it definitely made mercurial much easier to comprehend. Well written and very easy to understand. None of the documentation written for git comes close. I for one, find most of what is written by Scott Chacone (who has singlehandedly written most of the documentation/books about git) particularly confusing.

Not the answer you're looking for? Browse other questions tagged or ask your own question.