Let me try to answer at a high level first. I use git for all of my workflows and when I collaborate with other people on my team, we use git and github. See, for instance:
https://github.com/unicorn-wg/gecko-dev/tree/multistream_rebase So, I primarily need to engage with hg for the following tasks in descending order of frequency. - Posting patches to bz (or I guess rb in the future) - Downloading other people's patches for tryout - Pushing to try - Landing code I don't much mind the last one of these. It's a PITA, but I don't do it very much and I hope in future to use autolanding, so not such a big deal. On Thu, Oct 30, 2014 at 10:48 PM, Gregory Szorc <g...@mozilla.com> wrote: > 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? > As far as I can tell, yes. > Does anyone use hg-git (it has gotten *much* faster in the past year > thanks to Facebook's investment)? > I use it for working with NSS because there is no official NSS github mirror. If there were, I would use that and not use hg-git. 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? Not very. > Short of switching the canonical repositories to Git, what do you need to > be more productive? > Tools that would let me use git without a local hg repo. - > 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.) > This would make me extremely sad. -Ekr > > Gregory > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
