On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla <e...@rtfm.com> wrote:
> Generally no, but this is an unfortunate consequence of Mozilla's decision > a while ago to pick a VCS which has not turned out to be the dominant > choice (not placing blame here, but I think it's clear that's how it's > turned out). The result is that a lot of people want to use git and that > means git needs to have a first class experience. > I've been using git for years now to develop Firefox, and I feel like it is a first class experience. There's a one time cost to setting up cinnabar, but after that, everything just works, including |mach try| and |mach mozreview|. It is still probably less setup than Mercurial users have to go through to install enough extensions to make hg usable. ;) Sure, there's a bit of "wacky custom machinery", but developers using hg also have to deal with some of that, so that's more of a Firefox developer problem than a git Firefox developer problem. Andrew > -Ekr > > > > Originals to end. > > > > > > On Mon, Sep 18, 2017 at 5:16 AM, Eric Rescorla <e...@rtfm.com> wrote: > > > >> On Mon, Sep 18, 2017 at 2:56 AM, James Graham <ja...@hoppipolla.co.uk> > >> wrote: > >> > >> > On 18/09/17 04:05, Eric Rescorla wrote: > >> > > >> > But that's just a general observation; if you look at this specific > >> case, > >> >>> it might not be much effort to support native git for richer/future > >> try > >> >>> pushing. But that's very different from requiring all the tools to > >> >>> support > >> >>> native git on an equal basis. And it seems reasonable to evaluate > the > >> >>> utility of this specific support via a poll, even one known to be > >> biased. > >> >>> > >> >>> > >> >> I don't think that's true, for the reasons I indicated above. Rather, > >> >> there's a policy decision about whether we are going to have Git as a > >> >> first-class thing or whether we are going to continue force everyone > >> who > >> >> uses Git to fight with inadequate workflows. We know there are plenty > >> of > >> >> people who use Git. > >> >> > >> > > >> > I don't entirely understand what concrete thing is being proposed > here. > >> As > >> > far as I can tell the git-hg parameter space contains the following > >> points: > >> > > >> > 1. Use hg on the server and require all end users to use it > >> > 2. Use git on the server and require all end users to use it > >> > 3. Use hg on the server side and use client-side tooling to allow git > >> > users to interact with the repository > >> > 4. Use git on the server side and use client-side tooling to allow hg > >> > users to interact with the repository > >> > 5. Provide some server side magic to present both git and hg to > clients > >> > (with git, hg, or something else, as the on-disk format) > >> > > >> > These all seem to have issues relative to the goal of "vanilla git > with > >> no > >> > custom code": > >> > > >> > 1. Doesn't allow git to be used at all. > >> > 2. Requires a multi-year transition away from hg. Probably not > popular > >> > with hg fans. > >> > 3. The status quo. Requires using a library for converting between hg > >> and > >> > git (i.e. cinnabar) or some mozilla-specific custom scripts (the old > >> > moz-git-tools) > >> > 4. Like 3. but with an additional multi-year transition and different > >> > custom tooling. > >> > 5. Allows vanilla git and hg on the client side, but requires > something > >> > complex, custom, and scary on the server side to allow pushing to > either > >> > repo. Could be possible if we eliminate ~all manual pushes (i.e. > >> everything > >> > goes via autoland), but cinnabar or similar is still there in the > >> > background. > >> > > >> > >> This is what I meant. And having something complex and scary on the > server > >> side is (at least to me) obviously better than having something complex > >> and > >> scary (and did I mention constantly out of date) on the client side, > >> because it's all in one place and externally just looks like the thing > the > >> client is expecting. Note that we already have half of this because we > >> have > >> one-way synching to gecko-dev on the server side. Perhaps one could also > >> rip off some of the servo-gecko synching stuff here, but I don't know > much > >> about how that's architected. > >> > >> > >> Given none of those options seem to fit, the only other possibility I > can > >> > think of is to skip the general problem of how to interact with the > VCS > >> for > >> > try specifically by making submitting to try not look like a VCS push, > >> but > >> > like some other way of sending a blob of code to a remote machine > (e.g. > >> > using some process that generates a patch file). But unless there's > some > >> > extant way to achieve that it seems like it would be replacing > >> > known-working code (cinnabar) with new custom code. > >> > > >> > >> > So my best guess is that you mean that all pushes should go via > autoland > >> > and we should provide read-only hg/git repositories, and try pushes > >> should > >> > also go via something other than a vcs push. But I'm probably missing > >> > something. > >> > >> > >> Well, I do think this is the direction we should be moving towards, as > it > >> seems to have a pile of advantages. Indeed, if we're *already* going to > be > >> forcing people to submit to try via mach rather than via vcs push, why > >> wouldn't we do that for this piece of it now? > >> > >> -Ekr > >> > >> > >> > > >> > _______________________________________________ > >> > 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 > >> > > > > > _______________________________________________ > 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
