On Fri, Feb 12, 2016 at 11:06:04AM -0800, Junio C Hamano wrote: > 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. 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 -- 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