Executive summary: Both are very good. Mercurial tends to be playing "catch up" to git in the more elaborate (but very useful) functionality. Git on Windows tends to be rougher but it is catching up, maybe caught up. If you cannot decide, flip a coin and Just Do It[tm], it will be a win either way.
When I last used Mercurial heavily (around a year ago), its branching was weak so the user model tended to be clone to create a new repo as a branch rather than branching within a repo. Logically, this is the same, but practically it is less convenient... it tends to create multiple directory pollution and then you forget what is in which directory (especially when you have CRS disease). I understand Mercurial branching is catching up or caught up with git.
Mercurial is pure Python (sorta), which makes it more portable (sorta) but slower (sorta). Git is written in C, which makes it faster (almost always), but assumes a "reasonable" POSIXish OS environment, making it hard to port to Windows (solved now).
TortoiseHg is great on Windows. I have played a little with TortoiseGit - it appears to be as good as TortoiseHg on Windows, but that is a recent development.
Git has some killer features, starting with its near magical merging. As Linus points out, branching is easy - it is the merging that is difficult. Hg is on par with merging, so that isn't a big discriminator.
A unique feature of git is the "index" staging mechanism. This is very handy to pick out certain changes (with the "interactive" mode, even down to the line-in-a-file level) and check just those changes into your repository without having to either update everything as a lump or jump hoops to separate wanted and unwanted changes.
Another really nice feature is git's "interactive" mode which allows major patch rework/rearrangement - you can split, merge (squash), and reorder patches. This allows you to be anal-retentive on checking in your changes frequently and then rationalizing the forest of changes before pushing it upstream. (From what I've read, while it looks like you are "changing" history, in the bowels of the git metadata, all the state and sequence information is preserved.)
Git's rebase is very nice and very useful if used with discretion. Again, it looks like Hg has a rebase plugin now.
Personally, I prefer git because it is the repository for the open source projects I'm involved in and because my perception is that it is more popular and growing faster. If your development is in the Python world, you probably will prefer Hg for the same reasons. ;-)
The really good news is that you can move from SVN to Hg or git easily and you can move between Hg and git bidirectionally with only the conversion time as a penalty without losing any information. This means that, even if you pick the "wrong" DVCS, you can "recover" easily.
Hg's branching isn't weak anymore. The functionality of git and hg have converged to the point now that it's more a matter of a decision around inteface and community feel instead of features.
Mercurial isn't pure Python - a few hotspots (particularly diffing) are done in C. It seems to be easier to port, though. (Git has a thicker "Unix accent".)
When I last used Mercurial heavily (around a year ago), its branching was weak so the user model tended to be clone to create a new repo as a branch rather than branching within a repo. Logically, this is the same, but practically it is less convenient... it tends to create multiple directory pollution and then you forget what is in which directory (especially when you have CRS disease). I understand Mercurial branching is catching up or caught up with git.
Mercurial is pure Python (sorta), which makes it more portable (sorta) but slower (sorta). Git is written in C, which makes it faster (almost always), but assumes a "reasonable" POSIXish OS environment, making it hard to port to Windows (solved now).
TortoiseHg is great on Windows. I have played a little with TortoiseGit - it appears to be as good as TortoiseHg on Windows, but that is a recent development.
Git has some killer features, starting with its near magical merging. As Linus points out, branching is easy - it is the merging that is difficult. Hg is on par with merging, so that isn't a big discriminator.
A unique feature of git is the "index" staging mechanism. This is very handy to pick out certain changes (with the "interactive" mode, even down to the line-in-a-file level) and check just those changes into your repository without having to either update everything as a lump or jump hoops to separate wanted and unwanted changes.
Another really nice feature is git's "interactive" mode which allows major patch rework/rearrangement - you can split, merge (squash), and reorder patches. This allows you to be anal-retentive on checking in your changes frequently and then rationalizing the forest of changes before pushing it upstream. (From what I've read, while it looks like you are "changing" history, in the bowels of the git metadata, all the state and sequence information is preserved.)
Git's rebase is very nice and very useful if used with discretion. Again, it looks like Hg has a rebase plugin now.
Personally, I prefer git because it is the repository for the open source projects I'm involved in and because my perception is that it is more popular and growing faster. If your development is in the Python world, you probably will prefer Hg for the same reasons. ;-)
The really good news is that you can move from SVN to Hg or git easily and you can move between Hg and git bidirectionally with only the conversion time as a penalty without losing any information. This means that, even if you pick the "wrong" DVCS, you can "recover" easily.