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
tasks:
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 https://etherpad.mozilla.org/moz-git-tools 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
productive?
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.)
Gregory
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
