Re: Gated Merge?

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 12, 2016, 19:06 UTC
Message-ID: <xmqq1t8hvjdv.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160212190017.GA20801@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> 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.