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? > > 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
I've used git exclusively since shortly after a talk that Justin Lebar gave about using git at a work week in Toronto in Summer 2013. This was mostly motivated by git rebase -i being a massive improvement over the (at the time canonical) patch-based hg workflow. Since hg has gotten better I've continued to use git, primarily because git won the broader DVCS war and so using it is a useful skill to have. I maintain the canonical version of everything in git, and use hg only to push and attach patches to bugzilla. I use push-to-hg from moz-git-tools to export my changes to an hg repo, where I can either grab the files to attach to bugzilla or push csets to try. The aspects of the dual-VCS workflow that I find painful, in decreasing order of pain: 1. Changeset hashes don't match between the git and mercurial repositories. 2. git push-to-hg is slow 3. I have to have a bunch of hg repositories lying around taking up disk space for branches I might need to push to. These days code review and debugging occupies a large part of my time, so the friction the dual-VCS workflow has is not particularly bad (compared to build times on Windows, or how slow ./repo sync is on b2g, for instance). - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
