> I can't see how they are a good alternative. With patch queues, I can > maintain a complex refactoring in a patch queue > containing dozens of smallish patches. In particular, I can easily realize I > made a mistake in patch 3 while working on patch > 21 and make sure that the fix ends up in patch 3; I don't see how that is > easily achievable in git branches.
This is far easier to achieve in git than with mq. I this to a room of experienced hg developers a few days ago and got a loud chorus of "wow"s. But git isn't easy to use, and the fact that you think git can't do this is certainly evidence for that. >> * Developers can benefit from the better merge algorithms >> used by git. > > I don't know what you mean by that. Note that git's octopus merges are not > directly realizable in hg, so an hg-git bidirectional mirror may need to ban > such things in the incoming git. An octopus merge is not a merge algorithm. The merge algorithm is the thing that decides /how/ to merge two (or N) commits. > Mercurial also treats history as immutable, so you can't push history > revisions. History in git is no more or less immutable than in hg. Every time you hg qpop or qref, you're mutating history. On Thu, May 30, 2013 at 11:04 PM, Joshua Cranmer 🐧 <pidgeo...@gmail.com> wrote: > On 5/30/2013 7:56 PM, Johnny Stenback wrote: >> >> [TL;DR, I think we need to embrace git in addition to hg for >> Firefox/Gecko hacking, what do you think?] > > > Personally, the more I use git, the more I hate it. But I also see that > other people love it... > > >> * Developers can use git branches. They just work, >> and they're a good alternative to patch queues. > > > I can't see how they are a good alternative. With patch queues, I can > maintain a complex refactoring in a patch queue containing dozens of > smallish patches. In particular, I can easily realize I made a mistake in > patch 3 while working on patch 21 and make sure that the fix ends up in > patch 3; I don't see how that is easily achievable in git branches. > > >> * Developers can benefit from the better merge algorithms >> used by git. > > I don't know what you mean by that. Note that git's octopus merges are not > directly realizable in hg, so an hg-git bidirectional mirror may need to ban > such things in the incoming git. > > >> * Git works well with Github, even though we're not switching >> to Github as the ultimate source of truth (more on that below). > > > Outside of the community size, I personally can't see any benefits to Github > for Mozilla; if all you want is community outreach, you pretty much just > need a read-only git mirror on Github, which we already have. > > >> Some of the known issues with embracing git are: >> >> * Performance of git on windows is sub-optimal (we're >> already working on it). >> * Infrastructure changes needed... > > * Retraining Mercurial developers to use git (if we went git-only) > * Porting all of our Mercurial customizations to git for a check-in head > * Updating all of our developer build documentation > * Adapting build processes to adjust to the git way of doing things > > > >> Option 1 is where I personally think it's worth investing effort. It >> means we'd need to set up an atomic bidirectional bridge between hg and >> git (which I'm told is doable, and there are even commercial solutions >> for this out there that may solve this for us). > > > This is harder than it sounds: hg and git are subtly different in ways that > can seriously frustrate users if you don't pay attention. For example (one > that bit me very hard): hg records file copy/moves as part of the changeset, > while git attempts to reverse engineer them when it needs to do so. So my > attempt to merge my changes with a remote git repository via hg-git failed > miserably since the hg local repo didn't catch the git moved repo. Mercurial > also treats history as immutable, so you can't push history revisions. > > If all you need is a read-only mirror, these kind of changes aren't as > important (you're not going to damage official records, just inconvenience > some developers); for a two-way mirror, they are very much worth > considering. > > -- > Joshua Cranmer > Thunderbird and DXR developer > Source code archæologist > > > _______________________________________________ > 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
