I used hg-git to convert Mozilla's mozilla-central mercurial repository to git. It did the job and the resulting working tree checked out from git was the same as the mercurial one. With another tool I tried this wasn't the case.
It did use a lot of memory however when doing an 'hg push' into a git repository. It peaked at around 14 gigabytes of memory. Doing incremental updates it occasionally peaks at around that too.
I found that if instead I did a 'hg gexport' and then used the actual git command to push from hg-git's internal git directory to a git repository then memory usage was a lot less.
hg-git works great. I wish git and hg would settle on a common exclude file though. It gets annoying littering git repos with .hgignore and hg repos with .gitignore.
But usually you want to commit the things that you're ignoring (some of them, at least). You just don't want to do it twice, once in .gitignore and a second time in .hgignore. My solution is generally to put syntax:glob at the top of .hgignore and symlink it to .gitignore (or vice versa), so that edits to one of them affect both. Of course, I'm assuming that I'll never need to commit a file called "syntax:glob". I feel this is a reasonable assumption.
I started on Mercurial but have since been convinced that Git is definitely just as awesome, and a tad more flexible. The thing is, I will be sticking with Mercurial for my own projects because with bitbucket I can get private repository hosting with unlimited collaborators and it is free, whereas with Github I'd have to pay to get private repositories.
The real value of hg-git for me is that it made the git vs mercurial choice moot, since I can switch back and forth whenever I like. I started with Mercurial, and then switched to git after deciding that I liked it better. If I ever change my mind again, I can easily switch back. So I can stop arguing with myself and others over which one is better and start committing code.
I sort of wish I had something that went the other way. Nothing against mercurial, I just really like the git branching/rebasing workflow, and wish I could use it at work (where we use hg)
You can use it the other way. It's a little more awkward, though. Go to the github page: https://github.com/schacon/hg-git and scroll to the very bottom. Read the section on the "git.intree" option. After setting that to True, you can pull from a remote hg repo into your local git repo by doing "hg pull" (or "hg clone") followed by "hg gexport". Then do some work in git. Afterward, you can push from your git repo to a remote hg repo by doing "hg gimport" and then "hg push". You may wish to write git command wrappers git-hgpull and git-hgpush to automate those tasks.
I should note that I haven't actually done this myself.
It did use a lot of memory however when doing an 'hg push' into a git repository. It peaked at around 14 gigabytes of memory. Doing incremental updates it occasionally peaks at around that too.
I found that if instead I did a 'hg gexport' and then used the actual git command to push from hg-git's internal git directory to a git repository then memory usage was a lot less.