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)
Asked
Active
Viewed 5.3k times
9 Answers
239
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>" ];
then
GIT_COMMITTER_NAME="<New Name>";
GIT_AUTHOR_NAME="<New Name>";
GIT_COMMITTER_EMAIL="<New Email>";
GIT_AUTHOR_EMAIL="<New Email>";
git commit-tree "$@";
else
git commit-tree "$@";
fi' HEAD
Mercurial Version:
authors.convert.list file:
<oldname>=<newname>
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.
80
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.
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.
Cyclops
- 2,167
47
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:
- 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.
- 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.
- 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.
Alex Miller
- 447
29
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.
Rook
- 19,947
9
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.
7
There are a few things that IMO are likely to put new users off Git:
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.
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.
Documentation and inherent complexity:
$ hg help log | wc -l 64 $ git help log | wc -l 912
jammycakes
- 1,150
3
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.
haziz
- 499
3
One thing I can think of is
git add .
git commit -am "message"
vs.
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".
Zhehao Mao
- 883