I find Mercurial easier to use, even though I use git much more. I also find it harder to shoot myself in the foot with Mercurial - I've destroyed (but not lost) work with git quite a few times.
Mecurial is super easy to learn - there is no reason not to be comfortable with both.
> I've shot myself in the foot a few times with git, however, git reflog is _often_ there to help.
Many times this. Git reflog is an extremely powerful feature to fix mistakes. Any git user should at least in base understand what the reflog is and how it can be used for roll-backs.
I don't know what the wins of hg are. Used it for a year
Git has git style branches which make it really easy to work on different things. Apparently hg added some of that later but it's not the main workflow
git also has a "staging area". You put things into the staging area and then commit. So for example the equivalent of "hg commit" in git is "git commit -a". The -a means "copy everything that's changed to the staging area".
The advantage of the staging area is it's easy to commit just a few files even if many have changed. It's even easy to commit just a few changed lines from a file and leave the other lines un-commmited.
There are other advantages I'm sure and I'm sure I didn't explain the branching one well. I can point out that I have repos with completely unrelated branches. One branch is the website, another branch is the docs, another branch is the source code, branches in hg, at least the default ones, are assumed to be something that will eventually be merged back. hg complains forever until you merge the branch back. git branches are effectively unrelated to each other, although by default git will track where it branched and if you happen to merge them where they merged. branches can be pushed and pulled to other repos or not, it's up to you.
Someone above said hg has bookmarks that are similar to git branches but I'd be curious if they're actually the same.
