> The UX of hg was more intuitive for users coming from SVN and CVS
I second this. Trying to go from SVN to git left me confused and frustrated, while I found it much easier to switch to hg. Once I had been using hg for a while, I found that I had absorbed enough of the difficult/confusing stuff that switching to git was relatively painless.
1. The UI is more consistent ie. the "update" command only does 1 thing updates your working directory to a specified state.
2. It doesn't have a pre-commit staging "index" like Git (or it at least doesn't expose it to the user. So workflow is a bit for straightforward ie. you don't need to constantly "add" files before you commit, it automatically does it for you.
I personally love the staging component of git and would be lost without it. I often write a bunch of code working through a problem, because I think best that way, but it makes for a maintenance chore and a poor commit history, so I stage it into multiple commits when I'm done. This is absolutely trivial in git compared with other programs.
Plus, while the UX of git is not intuitive, especially from SVN, if you want to bypass staging and just use it like SVN, you can "git commit -a". Like svn, if you have new, untracked files, you can "git add -A; git commit". This is also trivial to alias.
I've used both extensively and I think they're virtually identical. Mercurial is a bit nicer because it's written in Python, but git has github going for it.
In my experience, once you get into more complicated commands like rebase, I had to read a lot of docs to get things to work in both systems, so I'd say hg is easier to get started with but they're on par overall in terms of complexity.
As a sidenote, I think the ability to `rebase -i` work branches and squash, edit, and drop changesets is a very useful feature, and it's made very easy in git. Mercurial can rebase branches, but it really doesn't like it...
hg's command-line interface is far better organized, yes, at least in the sense that it appears to have been organized rather than organically slapped together and papered over with "well it'd make sense if only you understood more about it".
Blaming users for not understanding a bad interface is one of the classic mistakes.
hg's original workflow didn't encourage git style branches at all nor did it have any kind of stage IIRC. They've since been optionally added. Is that workflow in hg more intuitive or is only its far less powerful original workflow more intuitive?
It took me a while make the mental jump from svn style branches to git style and from no stage to having a stage but I'd never want to go back now that I understand them.
This is not about workflow (though I do prefer hg's model of multiple types of branch-like constructs). This is about the command-line interface used to interact with it. Where git overloads commands (the same command can do vastly different things depending on options or context), or cannot make up its mind whether to implement functionality through top-level commands or flags to existing commands, hg is much more consistent in having a set of commands whose names match the operations they perform and are not overloaded with multiple contextual meanings.
For simple workflows (and certainly for beginners), hg is far easier to use than git. However when it comes to advanced usage, I personally find git more intuitive and frankly more powerful.
Granted, I learned git first and had been using it for 6 years before using hg.
Search results for "how do I branch in Mercurial" always seem to lead to elaborate tutorials that suggest repo clones or bookmarks or numbered anonymous heads or smuggling diffs outside the commit graph using an extension. If the simple use cases don't include branching, that seems like a big problem for a DVCS.