On 10/31/2014 11:03 AM, Ehsan Akhgari wrote: > On 2014-10-31 12:51 PM, Gregory Szorc wrote: All problems in computer > science can be solved by another level of >> indirection. The problem here is that Git users need to push to the >> canonical Mercurial repositories (inbound, try, etc). You will be >> hearing me say this a lot in the months ahead, but "Autoland changes >> everything." > > I don't understand how. Doesn't Autoland still require you to push > your changes somewhere? If that somewhere is an hg repo we're back to > square one.
I think the idea is that Autoland removes the absolute requirement to have the same base commit. You could theoretically feed it changes any number of ways, and it will attempt to do the rebasing on your behalf. You could use an hg repo, a git repo, a POSTed patch file, or whatever. Autolander would still have to puke the patch back in your face if it couldn't rebase (and therefore it should try to use whatever context you can tell it about the base revision you developed the patch off of), but at least it provides an extra layer of indirection that enables more flexible patch ingestion. Or perhaps I'm full of crap and gps meant something else entirely. :-) > >> With Autoland in place, there is a level of indirection between the user >> and landing: a landing queue. In my utopian end state for Autoland, no >> user - whether they use Git or even Mercurial - are pushing directly to >> the canonical repositories. Only the Autoland agent performs that role. > > FWIW I think that's a bit too eutopian. I have no hopes of > eliminating all of the need for pushing stuff manually. "Land this > thing at some point in the near future" is a very common use case but > it's far from being the only one. > >> Suddenly the publishing workflow becomes unidirectional and this whole >> syncing problem with Hg<->Git SHA-1 maps becomes abstracted away into >> the implementation of Autoland. We can stand up Git servers to allow Git >> native ingestion, without burdening Git users with the knowledge, >> overhead, or cognitive dissonance of Mercurial. > > Not sure if I follow. Are you suggesting that git users push to their > own vanilla git server, and then autoland comes around some time > later, converts that into hg, and tries to transplant the result? Why > is that better than just having a git server that pushes to an hg > server before accepting a push? That seems to both address the use > case of pushing to Autoland's hg repo, and also the use cases that do > not involve Autoland. I guessing it's not different at all, and that would be a component of Autoland. > Since you keep mentioning this (and *without meaning to start a flame > war*), let this be on the record that I think mercurial's > extensibility etc don't really matter for a user of the VCS, unless > they work in a very specialized environment (such as the big silicon > valley tech companies that have used hg in the past few years). > Productivity is subjective, and not an objective property of either > git or mercurial. The reason I and others go through this pain right > now to avoid having to use hg more is increased productivity. So, I'd > appreciate if you didn't make it sounds like mercurial is all about > user productivity and git isn't. :-) That's not how I interpreted gps's comments. I understood him to be saying that it is easier to customize hg, to adapt it to extra requirements or expanded/complex workflows. Which is different than saying one or the other is better for productivity out of the box. In performance terms, it's like saying that hg is good at scalability. And scalability is different from, and often opposed to, raw throughput. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
