Before I get to complaining (which I love to do), first let me say thank you for all the amazing hard work you've put into improving the developer experience! The improvements between when I started almost 4 years ago and now are nothing short of incredible.
I use git exclusively. The only time I touch hg is to clone a local bridge repo (which happens once per machine, when I get a new one - so not very often). I have some scripts I've written (Patrick has already mentioned them) that are effectively the same as moz-git-tools, but written either before I knew of moz-git-tools' existence, or when I had a severe case of NIH syndrome, I'm not sure which :) These scripts are pretty customized to my workflow, and I've put a decent amount of time into them, which is why I haven't switched (though I did shamelessly steal the "find matching base commit" functionality from moz-git-tools). On Thu, Oct 30, 2014, at 22:48, Gregory Szorc wrote: > a) Landing code to inbound, fx-team, aurora, etc For inbound, I use my scripts. For any other branch I may need to land on (aurora, beta, release (I hope not!)), I'll just attach a patch to the bug and set checkin-needed. I'd do that even if I were using hg, as I don't want to have to watch the tree :) > b) Pushing to Try My scripts for this, as well, based on a m-c hg bridge repo. > c) Fetching new commits Git fetch (from git.mozilla.org) > d) Collaborating/sharing commits with others, especially hg<->git sharing I'll either push a branch to my github fork of gecko-dev, or attach a patch to a bug. For attaching patches to bugs, I use my scripts to create a patch on disk and manually attach it, similar to manually pulling a patch out of an mq for hg users. I don't know why I've never used anything like git-bz-attach... inertia, I guess? > 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. For the record, this is exactly how my scripts work, as well. > 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.) Somewhere between satisfactory and barely tolerable, with an occasional bit of horrible pain thrown in. The advantage to using my own tools instead of moz-git-tools is that I've been able to customize them for the way I like to work, and have eliminated most of the serious pain points for my particular workflow. This, of course, doesn't necessarily apply to other workflows :) The biggest sources of pain for me are (1) the extra disk space required for the m-c and inbound bridge repos, and (2) doing the patch conversion can be slow... both because finding the matching base commit (which I do for try pushes only) takes a while (I don't have a copy of the git<->hg sha mapping), and because I often have a lot of commits that get turned into patches and applied to the mq of the hg repo. My scripts automagically squash the patches into sane commits for landing on anything other than try, so this is really only a problem when pushing to try. It still sucks, though. > Is moz-git-tools the de facto standard for Mozilla developers? Are there > other competing tools? moz-git-tools is definitely the de facto standard, I wouldn't consider my tools competition. > Does anyone use hg-git (it has gotten *much* faster in the past year > thanks to Facebook's investment)? I've tried it periodically, but it still seems painfully slow every time I try it. So much so that I've basically written it off as a viable alternative. > 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? I really wish I could eliminate local hg completely. It's pretty ugly to have to do this. > 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? The one thing I want (which keeps coming up, and seems to never go anywhere) is a git repo that I can push to, both for try and for landing on inbound or other branches. I would probably be ok if that landing capability only existed for integration branches... like I said above, if I need to land on any branch that requires tree-watching, I'll just put a patch on a bug and set checkin-needed. I'm lazy like that :) > 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 incredibly sad, TBH. We have a lot of people around here who use git, and we should be doing what we can to make us less second-class citizens. I know it's a lot of work, and I think we all recognize how much effort you and others have been putting in to make things significantly better, and that's beyond awesome! I just don't want to see those of us who use git to be forced to choose between a bad workflow that involves git and a bad workflow that involves hg (which, for me at least, is pretty much any workflow that involves hg - I keep trying and none of the available workflows work for me as well as my git workflow, as painful as it may be when landing code). -- Peace, -Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
