Git -> Hg workflows?

Gregory Szorc gps at
Thu Oct 30 22:48:29 PDT 2014

I'm trying to learn more about how the people who use Git for 
Firefox/Gecko development manage interacting with repositories that have 
their canonical home in Mercurial (mozilla-central, Try, etc). I'm doing 
this to ensure the replacement Try architecture will be usable by Git users.

I'm looking for more information and trying to tease out the relative 
popularity and pain points of the technical solutions for the following 

a) Landing code to inbound, fx-team, aurora, etc
b) Pushing to Try
c) Fetching new commits
d) Collaborating/sharing commits with others, especially hg<->git sharing

I found and the like-named 
GitHub repo with a suite of Mozilla-centric Git commands. These seem to 
be largely based on top of low-level patch format conversion and make 
little attempt (if any) to preserve commit SHA-1 mappings to enable 
bi-directional conversion (i.e. they are unidirectional, lossy tools). 
Many of them seem to have `hg` invocations buried under the covers.

I'm interested in knowing how people feel about these "hidden hg" tools. 
Is going through a hidden, local hg bridge seamless? Satisfactory? 
Barely tolerable? A horrible pain point? (I noticed some of the hg 
interactions in moz-git-tools aren't optimal. If these are important 
tools, please ping me off list so I can help you improve them.)

Is moz-git-tools the de facto standard for Mozilla developers? Are there 
other competing tools?

Does anyone use hg-git (it has gotten *much* faster in the past year 
thanks to Facebook's investment)?

I'm particularly interested in knowing if any Git developers have been 
able to eliminate local hg completely. i.e. you are fetching and pushing 
from/to Git repos exclusively. If so, what are you using? What 
limitations do you have?

Overall, how happy are you with your Git fetch/push workflows? Short of 
switching the canonical repositories to Git, what do you need to be more 

I'm asking all these questions because I'm helping design the 
replacement architecture for Try and the more optimal solutions that 
will deliver a faster and better user experience tend to be easier to 
implement for Mercurial and may partially preclude Git because, well, 
Git just doesn't have the extensibility points as Mercurial (yay 
extensions and dynamic programming languages). I'm not saying Git users 
would be locked out: I'm just saying that having Mercurial running 
locally and "proxying" certain actions through Mercurial (like Try 
pushes) keeps more options on the table. It also means we have to 
design, implement, and maintain 1 server interface instead of 2. From my 
perspective, I like the server-side simplicity. But I'm also largely 
ignorant of what Git users are going through. I'm trying to gauge 
whether additional effort is warranted to placate the Git crowd. I'd 
like to gauge things like e.g. how loudly people would scream if one day 
I announced that pushing to Try will require a Mercurial extension. (If 
that day comes, the carrot would be near instantaneous pushes with no 
contention and infinite server-side scalability to millions of pushes.)


More information about the dev-platform mailing list