I use both extensively (git for most personal projects, Mercurial at work), so I feel like chiming in here. I really do think that Mercurial's user interface i

I use both extensively (git for most personal projects, Mercurial at work), so I feel like chiming in here. I really do think that Mercurial's user interface is easier for beginners to pick up, and more difficult to shoot oneself in the foot with. It's the little things, like the fact that Mercurial's push and pull commands do exactly the opposite of one another, that hg clone/pull URLs are identical to what you type into a web browser to browse the repo, and the ease of dealing with Mercurial "bare" repositories (hg up -r null) for mirroring and backup purposes. And the way Mercurial's command-line interface strongly discourages one from modifying history; it makes it harder for things to get messed up on a small team coordinating with a shared-access repo. Yes, I know git has the reflog, but in general people seem to have much fewer "OMG WHAT JUST HAPPENED TO MY BRANCH" moments with Mercurial than with git. That (along with mq, which provided a unique solution to our team's needs) was the major reason I chose Mercurial over git at work. If we're going to brandish about the term "UX" here, then I'd say Mercurial definitely has a better "UX" than git. But Mercurial has pain points, too. The biggest one, in my opinion, is the way branches work: Mercurial started out with named branches, which it seems the community has recognized as a mistake, and has moved to replace with git-style branches (called "bookmarks" in Mercurial land). These work better, but there are still some drawbacks: for one thing, Mercurial lacks the notion of a "remote", so unlike in git your local bookmarks and remote bookmarks have to share the same namespace. This leads to counter-intuitive behavior when it comes to synchronizing bookmarks with a remote server, and often you'll find that bookmarks aren't necessarily updated when you'd expect them to be. Additionally, the notion of a "tip" makes working with feature branches frustrating, because by default Mercurial will check out from whatever branch was pushed to most recently, rather than a de-facto standard "master" as in git. Hand in hand with this complaint, by default Mercurial will want to push all your changesets, not just those under your current working bookmark, so you have to constantly specify e.g. "hg push -r master" to keep from pushing local throw-away branches. And it's not easy to delete local throw-away branches if you decide you don't want them (the downside of Mercurials aversion toward history modification), so one generally winds up using a separately-cloned repo for temporary work, which is unfortunate in contrast with git. Mercurial and git are both great, efficient, high-performance tools. But if I had to generalize, I'd say that Mercurial is better for beginners and for "enterprisey" usage, whereas git, despite its interface inconsistencies, can be more powerful once you fully understand it and its data model (but only if you aren't working primarily on Windows, and don't need Mercurial Queues).