On Tue, Sep 19, 2017 at 9:20 AM, Andrew McCreight <amccrei...@mozilla.com> wrote:
> 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. > This matches my experience, FWIW, at least on mac and linux. I haven't tried on windows. > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
