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)
locked by Thomas Owens♦ May 26 '14 at 15:39
This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.
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.
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.
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:
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.
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.
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:
One thing I can think of is
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.
protected by maple_shaft♦ May 25 '14 at 12:44
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site.
Would you like to answer one of these unanswered questions instead?