Re: Gated Merge?

[Jeff King <peff@peff.net>]

On Fri, Feb 12, 2016 at 11:06:04AM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > But I don't think this needs to have anything to do with merges in
> > particular, or rules like "when merging a branch that does not have me
> > in it". It is about saying "from here on out, the tree state should
> > match this property, and we can test it by running this script". And
> > then running "make code-lint-tests" becomes part of the acceptance
> > testing for a proposed topic merge, just like "make test" is already
> > (and likewise, people forking _new_ branches from master after the topic
> > is merged would make sure they do not fail the code-lint tests before
> > even submitting the topic).
> 
> That certainly is true, but this strays more and more from my
> original motive of implementing an automated evil-merge scheme that
> is better than what I currently have.
> 
> We try to do our tree-wide refactoring in such a way that it would
> break the compilation (by changing function signature) when we can.
> Catching with "make test" would certainly generalize it, but the
> endgame result I was shooting for was to come up with a solution for
> each topic in-flight just once and keep replaying it until it is
> merged.

Yeah, that makes sense. I do repeated merges myself, and it is a pain.
I do not usually use your Reintegrate scripts, though when I have done
so, they work pretty well. And I don't think you're going to come up
with anything much better for the general case.

Let's split the problem into "detect a problem" from "apply the fix for
a topic".

You do not want to stop detecting once the original topic is merged. The
new rule is "we spell this as FORMAT_PRINTF" and you want to detect it
in simultaneous topics, _and_ in future topics. So if it is worth
checking in an auomated way, that should go into the tree.

So once we've detected a problem, how do we fix it?

For the specific case of FORMAT_PRINTF, you showed a possible "extra
processing" snippet to fix the problem in an automated way. But if we
realize that these gated attributes are really just another form of
test, it should be obvious that we cannot do so automatically in the
general case. You do not expect to fix a failed "make test" on a merge
in an automated way; there are too many possible resolutions. The best
we can do is detect the problem, create a patch, and then apply that
patch as appropriate.

So I'm somewhat doubtful that it would be worth the effort to create
infrastructure for "automate this fix" that is anything except "apply
this patch and tell me if we now pass the test".

-Peff