Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html