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.
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.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
