I’ll just C&P and update the last time I wrote what was so awesome about hg:

Here’s a list of Mercurial features that I think are really cool:

• Revsets – a domain-specific language for querying your commits
• Filesets – a domain-specific language for selecting files
• Templates – a domain-specific language for altering the output of almost every command. Putting these together you can do things like this.
• Evolution – a distributed and safe way to share rewrites (think automatically recovering from upstream rebase without any git reset –hard and no git push –force).
• Absorb – automatically amends an entire stack of WIP commits at once by picking the right diffs from your working directory based on which commits’ contexts they fit best.
• Curses interface for hunk-picking – a unified interface for splitting diffs for any purpose: whether to revert working-directory changes, write a new commit, uncommit parts of a commit, or amend a commit with more diffs. Just add –interactive to any of those commands and start picking hunks!
• Curses interface for redrafting your commits – think git rebase -i with a curses interface (this is quite new, in the lastest relase; I’ve made a few UI tweaks to it that should show up in the next release)
• A fairly rich built-in web interface – hg serve and point your browser to http://localhost:8000 and you’re good to go.
• Lots of support for monorepos – indeed, this is the main reason that Google, Facebook, and Mozilla are all pouring work into hg and are using it.
• A consistent UI – this one is more subjective but often-touted feature of Mercurial. If a command accepts a revision/hash/tag/bookmark; it always uses the -r/–rev flag for it (and you can also always use a revset for any command that accepts a revision). If a command allows hunk selection, it always uses the -i/–interactive flag for it. The help for every command fits in about a screenful; no never-ending man pages full of arcane flags and explanations you don’t understand nor care about.

Give it a try! Mercurial is neat!

For 90% of your workflow, there’s no big difference. The other 10% can be painful to get used to. For instance, Mercurial does not have Git’s concepts of “staging area” and “tracking branch”, which simplifies things.

I’m more comfortable with Git purely because I’m used to it but I’ve recently taken a liking for Mercurial. It feels sturdier and more consistent.

Edit: I forgot to mention that Mercurial is very modular. Not only are there various extensions to simplify your workflow, you can write your own extensions to suit the needs of your project.

mostly a sane UI/UX. But also it’s easily extensible with python, and it has neat things like revsets.

I wrote an article about it, to copy/paste some relevant parts:

My chief gripe with git is its user interface. With ‘user interface’ I mean the commandline user interface. Let me show by example:

$ git help commit | wc -l
506
$ hg help commit | wc -l
59
$ hg help commit -v | wc -l
96

Currently my git installation has 169 “core” commands:

$ find /usr/lib/git-core -maxdepth 1 -type f -executable | wc -l
169

Compare this to mercurial’s 50 built-in commands (from hg help), a number which has remained constant since I wrote this article (whereas git had 160 commands when I first wrote this 2 years ago).

“But git commit has so many more features”, well, perhaps. But how many of those are actually used by most users? Mercurial can be easily extended, and most “missing” features are implemented in extensions (many are shipped with the base mercurial install). For better or worse, git is bloatware, and like most bloatware it comes with a [notoriously difficult to understand manual][git-man].

Mercurial has a manual and user interface that I understand without too much effort, and this is by far the biggest reason I much prefer mercurial over git. If I need to know something from mercurial I can just read the documentation and go ‘ah’, with git … not so much. There’s a reason so many of the [top Stack Overflow questions][so-top] are about git.

Some might say (and indeed, have said) that I’m lazy and just need to spend more time and effort learning git. Well, perhaps, but the thing is, git doesn’t really do anything. Unlike a programming language or API I can’t really build anything with it. It’s merely logistics to facilitate the actual building of stuff.
It seems to me that ideally you want to spend as little as possible time on logistics, and as much possible time on actually building stuff. I know enough git to get by, but not enough to deal with rare exceptional situations that occur only a few times a year.

Broadly, they both have comparable functionality (at least for what I need), but mercurial is more friendly where git is more flexible. By and large, hg stops you from doing things that you probably don’t want to do, and makes the most common actions easy.

That said, I switched to git a few years a back and am happy with the move. It seems trivial, but one thing that I prefer in git to hg is the ability to manipulate branches. In git a branch is just a reference to a commit, and so can be moved, renamed, deleted. In hg branches are a core part of how the repo is structured and can’t be changed. If you use a feature-branch strategy, this leads to either a) a lot of old, essentially dead branches or b) hacky workarounds using bookmarks.

This is somewhat indicative of the overall experience - hg is simple if you use it the expected way, but gets messy otherwise. Git is always a bit fiddly but is far less prescriptive.

That said, it’s expected to become paid at some point, no? Or has that changed? As much as I fully respect and understand this decision, i.e. that infrastructure and @sircmpwn’s work is not running on pink ponies farting rainbows, I’m kinda afraid of it creating a barrier for potential contributors to my open-source projects in future, in case of people who can’t afford a subscription.

edit: Or, of missing on network effects and random (potentially brilliant) forks in case I were to host my own instance.

Sorry for this sounding FUD-ish, I just don’t know how to phrase it in any other way.