It is definitely not. I wrote in another comment, there was a time when hg was leading in popularity (for the right reason: good ui), but git won for the right reason: everything else.

Could you outline what it is that you think makes Git better?

From my daily experience with both Mercurial and Git, i would say the exact opposite. I can't think of anything that Git does better than Mercurial. I can certainly think of things it does in a needlessly more complicated way - the handling of remote tracking branches and the use of the index are obvious ones. Git's fixation on branches over commits is a persistent deep source of pain for users around me. And you can pry revsets from my cold, dead hands.

Now, there was a time when Mercurial didn't have bookmarks. During that time, if you wanted a good lightweight branching model, Git was your only option (er, well maybe bzr or Darcs were, who knows). I was never that excited about lightweight branching; the weight of heavyweight branches does not seem substantial. Today, Mercurial has bookmarks that work pretty much like Git branches, so this advantage has evaporated.

Also, in a world of worse-is-better defacto software standards I'd say the choice between hg and git almost doesn't matter. I mean thank god people pulled their heads out of their asses enough to actually let Subversion lose the trench holy wars inevitable with the kind of sea change DVCS represented.

In my experience I have found Mercurial to be slower and less flexible. I use both on a regular basis.

When was the last time you looked at Mercurial? Recently the community put a lot of effort into performance and it should be very close to git's performance. On the flexibility site, Mercurial has the histedit extension as well as rebase which should give you most flexibility. The bare Mercurial is intended to not do much, but you have to enable a few of the shipped extensions in order to get all the functionality.

In particular, I wouldn't use mercurial without a .hgrc like this:

   [ui]
   editor = emacs -nw

   [extensions]
   color =
   pager =
   record =
   graphlog =
   purge =
   progress =
   transplant =

   [pager]
   pager = LESS='FSRX' less
   attend = annotate, cat, diff, export, glog, log, qdiff, heads

histedit and rebase are also useful but not for my usual workflows.

For the record, you don't need to enable the transplant and graphlog extensions anymore. Those are now part of core mercurial:

- The transplant extension has become the "graft" core command (do "hg help graft" for more details) - The graphlog extension functionality has been rolled into the core log command. You must simply use the --graph (or the equivalent -G) flag.

Not quite - graft doesn't support remote repositories, transplant does. I didn't know about hg log --graph, I think the muscle memory I have for hg glog will take a little while to break :)

Thanks for the tip.

You are right. That is a small limitation of the graft command compared to the transplant extension. As far as I know that is the only difference between them. I have never needed to do that so I forgot to mention it, sorry!

You can always do

   [alias]
   glog = log --graph

I guess.

Problem with histedit and rebase though is that they won't allow you to change published history. This means if I want to push my changes to a backup repository (not the main development repository) I loose the option of rebasing my feature-branch before pushing it to the main repo :(

No, problem with git rebase is that it allows you to do this.

Read this part of the git manual:

man git-rebase | grep -P "^RECOVERING" -A200 | less

Phases are actually a feature that git wants (last idea here):

https://github.com/peff/git/wiki/SoC-2012-Ideas

You have some ways you can work with this in hg using phases. One example is to mark the repo you're publishing to as non-publishing so that hg knows it's safe to edit history pushed to that repo. Another way is to just tell hg that you know better and to use "hg phase --force --draft" whatever commits you want to histedit or rebase.

Mercurial's phases are to Git as FreeBSD's jails are to Linux.

Ahh, didn't know about phases. Nice!

Take a look at Phases: http://mercurial.selenic.com/wiki/Phases

What you need is to make your backup repository non-publishing. Just drop these lines in your .hg/hgrc file inside repo:

    [phases]
    publish = False

I find Mercurial's porcelain more intuitive than git's, yes.

Could you elaborate on this? Do you mean CLI/UI?

Yes, I haven't used Mercurial too extensively (I use git), but Mercurial's commands make more sense to me. The only problem I have with it is that conflicts throw me into vim, and if I exit it to try and make sense of the merges, it thinks I'm done merging and leaves me in an unreasonable state, whereas git just marks the files and lets me resolve them at my leisure.

Using "hg help merge-tools" it describes some different merge tool settings that you might fine helpful. For example if you want it to merge all files it can, and mark the ones it can't fully merge you can try "internal:merge".

To set it for your user globally, in your .hgrc put "merge=internal:merge" under [ui].

Fantastic, thank you.

You probably need to disable a merge tool. Check 'hg showconfig merge-tools' and you'll probably find something. If this is on a debian derived system, I think that package maintainer turns on a bunch of stuff by default, so you may need to find a file in /etc/hg or similar.

Not that I use hg anymore, but if I remember correctly, exiting vim with :cq (returning an error code) solves that.

That's very interesting to know in general, thank you.

I feel Mercurial's commands are more intuitive than Git's, especially to former SVN users. Functionally, they're so similar it doesn't matter. This is why I love Kiln Harmony--I can work on a Git team and use Mercurial. Kind of like I can work on a dev team that uses Emacs while I use Vim. It shouldn't matter.

I work in a company that uses Git, plus Subversion for legacy stuff. I use Mercurial with hg-git and hgsubversion. There are occasional hiccups, but they mostly work like a charm. I'm happy because i get to use Mercurial, and my colleagues are happy because they have someone who can help them out by running complex revset queries!

Kiln Harmony was awesome, as I'm one of two developers in a team of eigth who prefers Git instead of Hg. Then we decided to use sub-repoes/submodules, and kiln harmony can't handle that, and our other team members simply WONT use git :(

I am totally with you on this, albeit kiln harmony is only available for managed hosting.

I've found that for general workflow, they're about the same, except that Mercurial has a slower checkout process and doesn't resolve conflicts as nicely. I'm not sure if there are features it has that git is missing..

In non POSIX systems it surely is.

If by that you mean windows: that's no longer the case. The git Windows installer is vastly superior to hg's windows experience currently. I'm using it daily and hg integrates really well into the system now. On top of that is tortoise git a very pleasant experience now.

I mainly mean Windows, but it is not the only non POSIX system around.

I am using Git on Windows on a current project and it is still far from what Mercurial was offering on my previous project in terms of usability and resilience to infrastructure issues.

> I am using Git on Windows on a current project and it is still far from what Mercurial was offering on my previous project in terms of usability and resilience to infrastructure issues.

Which part exactly? Git seamlessly integrates into Putty/PLink/Pageant and tortoise-git does the same. Git also has excellent support for end of line conversions. Mercurial last time I was checking required an extension to deal with line endings.

Git has had issues talking to the server, loosing credentials already stored, asks for the passwords multiple times, every now and then, a bunch of HTTP errors comes back when doing pulls/pushes.

The mercurial server is hosted on the same server and works without issues.