However, he and many git users enamored of his style are perfectly willing to be condescending to anyone who points out the problems. Which itself is a problem.
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.
Blaming users for not understanding a bad interface is one of the classic mistakes.
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.
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...
Granted, I learned git first and had been using it for 6 years before using hg.
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.
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.