Gregory Szorc <g...@mozilla.com> writes: > 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
I have an git alias hg-format-patch = !sh -c 'git format-patch -kp -U8 "$@"|tee /dev/stderr|xargs git-patch-to-hg-patch' git So I could use |git hg-format-patch -<n>| or |git hg-format-patch <ref>| as using |git format-patch|. That also ensures the generated patch has enough lines of context. I think git-patch-to-hg-patch is from moz-git-tools. The generated patches could then be upload to bugzilla for review or applied to a canonical hg repo and push. > b) Pushing to Try git hg-format-patch mozillaorg/master cd $hg; hg qimport $git/*.patch hg qpush -a hg try -m'try syntax' > c) Fetching new commits git remote update > d) Collaborating/sharing commits with others, especially hg<->git > sharing changes are published to github. Collectors usually pull directly from github or use patches attached to bugzilla. Kanru > 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 > 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
