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
