On 30/10/14 22:48, Gregory Szorc 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:
Mostly just using gecko-dev + moz-git-tools. > a) Landing code to inbound, fx-team, aurora, etc git push-to-hg > b) Pushing to Try git push-to-try > c) Fetching new commits git pull > d) Collaborating/sharing commits with others, especially hg<->git sharing Honestly, my experience is that this doesn't happen too much at the moment except via textual patches to bugs (git bz attach). It is maybe a bit offtopic for this thread, but I find that compared to other workflows I have experienced, the one for code that ends up in m-c seems to strongly discourage collaboration. Maybe my experience isn't typical, but as far as I can tell most bugs seem to be fixed by patches that are primarily the work of a single author. If code review identifies problems with a patch it is very difficult for anyone other than the original author to step in and help fix those problems. This is because there's no shared space where one can create branches that exist for the lifetime of a bug or feature and allow multiple developers to simultaneously contribute. Where larger projects absolutely require this facility they have to take a high-overhead approach and go through the process of renting a twig repository for the duration of their project. Where I want to share wip code with others (or myself across machines) I use github (my previous attempts to do this using mq were an unmitigated disaster). However this is effectively read-only unless I go through the effort of giving them write access to my gecko-dev fork, and they go through the effort of adding a remote. > 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. Yes, but I find I only use these at the edges of my workflow and try to stay inside git for as long as possible. This is imperfect of course. > 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.) It's satisfactory, but improvements would undoubtedly be productivity wins. > 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? git push working seamlessly. Switching to reviewboard makes this even more important. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
