Not really.  In my subjective(+) opinion, Hg Queues are designed to work around the suboptimal design of branches in Hg.<p><i>Mucking about with a lot of small commits</i> is a Good Habit and very useful when working from two different computers, but makes the Hg repository log terribly noisy.  Eg. it invariably results in several "Oops, I forgot to add imgs.idx in the last changeset." or "This does not compile, but I committed it for backup purposes because I'm updating from Vista to Win7.  Please check out the next changeset if you want to compile.".  Git naturally supports squashing of commits to solve this, while Hg sans Queues does not.  Git also allows you to kill off experimental branches that lead nowhere, while in Hg they live forever unless you make the "branch" in a queue ecosystem.<p>I will also pre-emptively counter a counter-argument which tend to always come up when I talk about this: "Swallow your pride; allow people to see your mistakes.":  It's not about that; it's about keeping the repository history somewhat <i>readable</i>.  Next week, someone on my team may have to look through all my changes for the code review, or in a few months when I'm on holiday someone might want to know what all the rework between versions 2.5.2 and 2.5.3 was so they can double-check that the release notes have been updated.  Leaving these people to wade through piles of "Ooops"-es and half-commits is just sloppy and unprofessional.<p>(+) Disclaimer: I use Hg extensively at work, and Git extensively at home.  I am frequently branching, merging, cloning, rebasing, squashing and generally mucking about in both, so I believe I know them fairly well.  I prefer Git by several orders of magnitude.