27

I currently use Git, and am generally happy with it, but I'd like to know more about Mercurial. Does it have any advantages over Git? What are the advantages of Git over Mercurial?

I realize there are already detailed comparisons of the two, but that's not what I'm asking for. I don't want dispassionate information, but rather impassioned (but polite!!!) reasons why you think one is better/easier/faster/smarter/stronger/etc.

iconoclast
  • 21,213
  • 15
  • 102
  • 138
  • 5
    See http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast for the dispassionate side, http://stackoverflow.com/questions/35837/what-is-the-difference-between-mercurial-and-git and http://stackoverflow.com/questions/2527276/git-mercurial-hg-opinion for more "passionate" opinions. – VonC Nov 28 '10 at 22:19
  • 1
    Should be Community Wiki really, since you seem to be asking for subjective answers. – Ben James Nov 28 '10 at 23:00
  • 1
    The *conclusion* that X is better than Y might be considered subjective, but the *reasons* are not subjective, and I asked for *reasons*. The fact that people are passionate about either Git or Mercurial doesn't mean that the facts on which they base their opinion are no longer facts. Facts are facts. Reasons are reasons, and I asked for reasons. – iconoclast Feb 28 '12 at 21:55

11 Answers11

28

I have used both Mercurial and git and I vastly prefer hg to git; it just feels nicer. Steve Losh in his blog post The Real Difference Between Mercurial and Git sums up most of my feelings about it. Here are some quotes which I agree wholeheartedly with:

I think there’s still one very, very important difference left: the systems feel very different to use.

I personally find Mercurial’s philosophy easier to work with. It’s easy for me to wrap my head around commands when they’re more modular and less monolithic.

I personally don’t like the index. I feel that git encourages people to check in changesets that contain code which they’ve never tested (or even built) because the index is such a prominent part of git’s workflow.

I've found the index a pain to work with - if I want something like that (and more powerful, too) I'll use mq. In the mean time - why should I be forced to have different types of adds, etc.? Why should I be forced to use git commit -a (and have git status - where is git st? - show weird info)?

Quite seriously, I personally can attribute the success and wide acceptance of git to nothing other than GitHub. Steve latches onto that, too. How may people have been through this, and "given in" to pressure from git users?

I don’t like using git itself (though it’s far better than SVN or CVS), but GitHub is such an awesome site that I’ve considered switching just to use it.

I'll continue to only use git/GitHib when required to - when I want to make a patch to something that's on there. My own projects will continue to use Mercurial. It feels nicer.

Chris Morgan
  • 86,207
  • 24
  • 208
  • 215
  • 4
    While I agree that GitHub is a strong influence, I think it's pretty unfair to say "nothing other than". (Much more important in that vein was the linux kernel!) Other answers here and elsewhere list definite advantages (like the ease of lightweight branching). Some of your complaints also seem dubious. How does the index encourage lack of testing? If someone will add then commit untested code, surely they'd just commit it if the index weren't there. I completely believe that Mercurial feels nicer and probably more intuitive to you and many others, but there's no need to nitpick to justify it. – Cascabel Nov 29 '10 at 14:23
  • 1
    @Jefromi: for things like the Linux kernel it's all very well, but I don't believe that explains its wide acceptance. While it was still even less usable than it is today it began to become popular (and that's why it's more usable today than it was), and I can only see GitHub as the cause for that. Concerning the committing untested code, read the rest of Steve's article and I think it makes a bit more sense. – Chris Morgan Nov 30 '10 at 00:29
  • 3
    I think you underestimate how big of a deal it can be for Linus Torvalds and friends to throw their weight behind something. In any case, GitHub wasn't launched until 2008. Git was at v1.5.4 then (nearly three years after v1.0), and was already quite popular and usable. GitHub certainly has contributed plenty, but git was solidly established before it. – Cascabel Nov 30 '10 at 00:56
  • 3
    I remember Git being by far the popular choice at the first acts_as_conference (January 2008). Github launched in April of that year. It was around in beta before launch, though, so it still may have had some influence. But things like Randal Schwartz's talk on Git were more influential for me. It seems to me that Github grew in part from the overwhelming consensus among Rubyists that Git was the future. In turn, Github made Git's position an even stronger one. (Does art reflect reality, or does reality reflect art? Both.) – iconoclast Nov 30 '10 at 23:05
  • And don't forget Mercurial is written in Python! :) – hochl Dec 05 '11 at 12:33
  • Since writing all this I have ended up using Git more and more (I’m down to using Mercurial only for private projects, really, and using Git for my own public OSS projects and at work), and I know it considerably more thoroughly than I did when I wrote this. I probably wouldn’t say that I *vastly* prefer hg to git any more, but I still do prefer it. I’ve come around to accepting the index and do find it convenient at times, but in the meantime Mercurial has sprouted its changeset evolution features which do a much better job still. – Chris Morgan Jul 29 '14 at 23:15
15

(A) Top 3 real reasons I use Git rather than Mercurial by choice:

  1. historical stochasticity / inertia
  2. historical stochasticity / inertia
  3. historical stochasticity / inertia

(B) Given the above, the top 3 things I like about Git over Mercurial:

  1. the index
  2. lightweight branches
  3. sane tagging (a tag is not a commit that follows the commit that is being tagged)

(C) The three things Mercurial has for it over Git:

  1. better native documentation (emphasis on native, because the ProGit book is simply outstanding, and anyone who has any complaints about Git or the Git model being too complex or confusing should go directly there)
  2. sequential commit numbering (local repository scope only, but I imagine this might sometimes be more convenient than cutting-and-pasting SHA-1's when fiddling about?)
  3. nicer logo/name?

I think that all (most?) of the items in (B) are either a result of me being used to the Git model due to (A) or can be "fixed" in Mercurial through plug-ins. But the fact remains that Git works the way I want it to out of the box, and I can live without any of the (C) items [given that C(1) is rendered a non-issue due to the excellent ProGit book]. And, so, I continue to use Git over Mercurial.

Sun
  • 2,110
  • 2
  • 21
  • 28
Jeet
  • 38,594
  • 7
  • 49
  • 56
  • 3
    I actually think sequential commit numbering counts against Mercurial. I love it that the same SHA1 hash means the same commit in any repository in the universe. (But it is crucial that those hashes can be abbreviated.) – Norman Ramsey Dec 09 '11 at 02:26
  • 1
    Another *real* reason for many people nowadays is GitHub. – Paul Draper May 26 '14 at 20:59
  • 4
    Regarding "I love it that the same SHA1 hash means the same commit in any repository in the universe. (But it is crucial that those hashes can be abbreviated.)": I would point out that Mercurial works exactly the same way. Each changeset has its own SHA1 hex ID. Identical IDs in related repos refer to the same changeset. The sequential numbering is specific to the local repo and it makes life easier working locally, compared to using the 40-character long (or shortened) IDs. I fail to see why it would "count against Mercurial". – AbVog Dec 21 '16 at 16:34
  • Mercurial has also an index/staging, and even more powerful than git has. It's called [Mercurial MQ](http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues). Mercurial has also lightweight branching called - bookmarks – Slimer Nov 08 '17 at 07:52
12

Main reason I use mercurial is because:

  1. It's supported at more open source repositories I generally use (namely, Bitbucket and Codeplex)
  2. It works well out of the box on Windows

Otherwise, as far as the VCS operations themselves are concerned, they're pretty much the same.

(EDIT: In order to clarify -- I'm not saying mercurial is superior -- to my understanding Git is faster than mercurial in general use, and I've not actually used git that much enough to comment. But these two reasons are why I'm using mercurial rather than git)

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • 1
    Hg doesn't merely work "well" out-of-the-box on Windows, it works _absolutely awesome_ there. I use hg on both a Linux and a Windows machine every single day and I literally don't have _single_ complaint about its performance, functionality or usability on Windows. – Lucas Dec 05 '10 at 13:24
  • @Lucas: Okay, it "works insofar as any VCS can work". Better? :P – Billy ONeal Dec 05 '10 at 16:47
9

No Mercurial and Git are very similar.

My personal opinion is that the differences are highly exaggerated and passionate and do not stand to greater scrutiny.

There are small differences.

Git tend to expose the model more than Mercurial. Mercurial tends to have a smaller subset of commands than Git and is reflective of that philosophy.

Mercurial has extensions for most other purposes

Most of the other stuff can be achieved by using the powerful extension model in Mercurial. It also has the advantage of easy extensibility as most of the Mercurial code is written in Python and you could run Extensions as if they are native Mercurial commands.

Some links

See the following discussion for additional information and details

The following provides a succinct view of differences between Git and Mercurial

Why, I prefer Mercurial over Git.

[Again a personal passionate and biased opinion]

The commands are truly a subset of what is available in Git and seems very sufficient. Any thing more, it feels like over indulgence.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
pyfunc
  • 65,343
  • 15
  • 148
  • 136
6

I use Mercurial because code.google.com supports it. I also use it because it is written (mostly) in Python and is easily extendable. It is also easily installed on many operating systems. Some people I work with are afraid of the commandline and like having the ability to use a GUI tool, so I point them to TortoiseHg.

Both have their pros and cons. Use whichever you are more comfortable with.

Bonus Link:

gitvsmercurial.com

gitvsmercurial.com via Wayback Machine

Post Mortem

Since writing this answer, I have become predominantly a git user, mainly because of GitHub. I have also began using Subversion at work. I would rather not be using Subversion.

kzh
  • 19,810
  • 13
  • 73
  • 97
5

6 of one, 1/2 dozen of the other. I switched from Mercurial to Git because another guy on my team prefers it. However, I think he prefers it only because he learned it first.

xscott
  • 2,350
  • 16
  • 18
5

I prefer git because:

  • It (seems) faster to me.
  • More built-in tools.
  • Higher availability of help, questions, and discussion (even on this site).
  • GitHub is incredibly useful.
  • There's a lot of active/cutting-edge development using Git right now, especially in the Javascript and Ruby communities.
arbales
  • 5,466
  • 4
  • 33
  • 40
  • 10
    What is the advantage of GitHub over BitBucket? BitBucket gives you free private repositories, so I think the points should go to mercurial there. – Wim Coenen Nov 29 '10 at 10:05
  • I haven't tried BitBucket, but GitHub is fantastic in so many ways. You have to try it to appreciate it. It can't be boiled down to the pricing levels, even though (as you point out) those may be better on BitBucket. (I'm not arguing that GitHub is better: just trying to at least partly answer your question as to why someone would point to GitHub as a reason to choose Git.) – iconoclast Nov 30 '10 at 23:17
  • 3
    Also, besides Github *itself*, there's all the code on Github. And that's what really matters, right? – iconoclast Nov 30 '10 at 23:18
5

When I was reviewing DVCS a few years back:

  • bzr was tied to Python 2.4 and wouldn't install/run on 2.5 out of the box.

  • git support on Windows was sketchy at best.

That left hg. I have been very happy with hg. The hg community seems to have an eye towards UX, which makes me, a user, happy. git UX seemed to take a long time to start moving towards "ease of use", which does not incline me to look favorably upon it.

There are a few things that I think hg needs to have: flexible metadata and big-file ease stand out. However, those aspects do not interfere with my regular use case and if I really need it, I can write/modify extensions without significant grief.

Paul Nathan
  • 39,638
  • 28
  • 112
  • 212
4

You can achieve equivalent things with both but that doesn't mean the differences are superficial.

Having used Git daily for a couple of years, and Mercurial daily for about a month now, I find there is a distinctly different feel to both.

My experience so far is that when collaborating in a centralised sort of workflow, Mercurial makes it more difficult to keep private development branches, without keeping multiple clones of the repository. With Git you have to be explicit about what you share.

So with Git it feels much less of a big deal to do casual hacking; maybe things you "shouldn't" be doing if it's a work project, for example. It lowers the mental barrier to trying out a new idea.

Since I like to be able to do whatever I want, on my own copy of the repository, and only share with others what I want them to see (and what is useful to them), I prefer Git because it seems to make this easier.

Another thing: I did get quite excited on first seeing Mercurial's Python API (since I'm a Python user). I thought I was going to have a great time writing extensions. Then I saw the warnings that the API is not guaranteed to remain compatible.

Since I'm lazy (a noble characteristic I think, having also been a Haskell dabbler at some point), I gave up that thought quite quickly and disappointedly.

Ben James
  • 121,135
  • 26
  • 193
  • 155
  • 1
    Your point about branching is, I believe, a *very* important one which I've often seen downplayed. Personally, I regard lightweight branching as a critical feature. Of course, I've heard that Mercurial bookmarks can help deal with this - and now they can even be transferred between repositories - so maybe it's not as much of an issue anymore? – Cascabel Nov 29 '10 at 03:56
  • Thanks for the tip, Jefromi. I have tried bookmarks now; while they are obviously lightweight, I don't see how they are easier to keep private (since every bookmarked commit is also on a branch, so will be pushed if you push that branch). – Ben James Nov 29 '10 at 17:10
  • Ah. I haven't really used mercurial myself; I've just read about bookmarks in the context of lightweight "branching" in mercurial. Sounds like there still is a real deficiency there. – Cascabel Nov 29 '10 at 18:28
2

While there are some usability differences (my main beef with Git is not enabling colour by default; Hg by default lacks a pager, color, a hack for colordiff, purge — just because there's an extension framework doesn't mean you shouldn't ship them and enable them everywhere), an important reason I've stuck with Git is that it has a lot more mindshare in the communities that matter to me. Despite Hg's early lead with the Mozilla project, Git has become the standard for the communities arbales mentions (particularly javascript and web infrastructure), Gnome, the kernel obviously, and the long tail of random projects I find useful.

Just because there are network effects doesn't mean marketing decided everything. Git's toolset is generative and terribly efficient (it's used in a lot of backup, archival, and data integrity stuff); Hg's extensions must be generative as well, but more at the level of ui enhancements. Git started some useful standards like fast-import. I think this is why it attracted more system builder types, who are a good seed both for improving git, completing it, and putting their stuff in git.

Tobu
  • 24,771
  • 4
  • 91
  • 98
  • 1
    Disabling colour by default should never be a reason to knock an application that's designed to run through a terminal. – elmt Nov 29 '10 at 00:47
  • If it's a tty and $TERM is sensible, why not? The pager already uses the same heuristic. – Tobu Nov 29 '10 at 00:56
  • 1
    Because historically, terminal applications do not have colour enabled by default. A valid example is the `ls` command which requires the `color=auto` option to be set. – elmt Nov 29 '10 at 01:07
  • 4
    I'd put a similar argument on Git's use of a pager - it should be `--pager` (or leave it to `|less`), not `--no-pager`. I don't *want* a pager normally. It's not *normal* for executables to use a pager. – Chris Morgan Nov 29 '10 at 01:29
  • 1
    But compare: `hg log` wipes the screen leaving me with the oldest revisions. `git log` shows me the recent ones and lets me navigate. One handles the common use case and the other doesn't. As far as tradition: is `man` abnormal? – Tobu Nov 29 '10 at 01:39
  • @elmt: the ls command is probably somewhere in the neighborhood of 40 years old. Git is somewhere in the neighborhood of 5 years old. The reasonable expectations one could make of the available terminals 5 years ago were different than those 40 years ago. So ls still suffers from the need to be backwards-compatible. Changing it now would probably break things. (And even if not, it's suffering from inertia.) – iconoclast Nov 30 '10 at 23:08
  • On the other hand, it's so easy to configure colors, so (while I agree they should be the default) it doesn't trouble me that much. – iconoclast Nov 30 '10 at 23:09
  • I focused on usability because both apps compete on it, and the popularity angle because it's what made this question a bit fresher (it's not the sole reason for my preference). People who answer here do remember what changes to make on a new install. – Tobu Nov 30 '10 at 23:27
1

Historical accident. I started using Git during the very few days before Mercurial was released. I kept using Git because I was too lazy to relearn.

IOW: Mercurial didn't exist when I started using Git, so I never actually made a conscious decision between the two.

However, there are a couple of things I like:

Community
  • 1
  • 1
Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
  • 3
    I'm a Mercurial developer, so keep that in mind... but when I just read the story of the "coolest merge ever" I must admit that I smiled :-) Linus uses 6 quite arcane commands to do some low-level trickery in Git. In Mercurial you do `hg pull --force ../other-project; hg merge; hg commit'. The only "trick" here is the use of `--force` since Mercurial wont normally let you pull from an unrelated repository. The rest is normal every-day commands, without any special options. – Martin Geisler Dec 03 '10 at 14:03
  • "Linus uses 6 quite arcane commands"??? git fetch and git commit are not arcane, although some of what is between them could be considered a bit arcane. (Nonetheless your point is well taken that this is very easy and straightforward in Mercurial. That's very useful to know!) – iconoclast Dec 29 '10 at 18:26