From: Junio C Hamano Date: Fri, 12 Feb 2016 19:06:04 GMT Subject: Re: Gated Merge? Message-ID: In-Reply-To: <20160212190017.GA20801@sigill.intra.peff.net> Jeff King 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.