I switched from hg to git for day-to-day development because b2g uses git; I was kind of forced to.

But now that I’ve learned enough git to get by (no small task; git is way harder to learn than hg+mq), the killer feature for me is: I don’t have to rebase my patches until I want to.

With hg, I’d commonly do something like the following:

1) Work on patches for bug A.
2) Forget about those patches for three weeks. In the meantime, I’ve hg pull -u’ed many times.
3) Try to push patches for bug A. Now none of my patches apply, and I have to manually apply the .rej files.
4) Go back to step (2).

With git, my patches for bug A are attached to a base revision of m-c which only changes when I want it to. This is a huge improvement!

I agree that there’s a difference between git and hg, but… well, the other way around. The majority of mercurial-using Moz developers seem to use mq, which is a much *more* flexible way to reorganize unpublished history. Base mercurial also has hg rebase, hg pull –rebase, hg crecord, hg qcrecord, etc. which seem to cover the same ground as the commands you listed. (Note that git has stgit and guilt, which are equivalent to mq, but seemingly less commonly used.)

I actually think there’s a more substantial difference in the common workflows with *published* changes — specifically, whether people want to maintain linear history (“fast-forward commits” in git terminology) or are ok with lots of branchiness. Both git and hg have similar support for both, but there seem to be social differences between the two communities. The one major functionality difference between the two — namely, whether commits are permanently associated with a line of development or not — is somewhat relevant, though there are good (and vehement) arguments on both sides of that question.

git itself is great (even though I like the hg commands better) and the DVCS workflow is also great, of course – but making ourselves dependent on a proprietary platform is not really in line with what Mozilla should advocate.