Junio C Hamano <gitster@xxxxxxxxx> writes: > To avoid unnecessary conflicts with in-flight topics, ideally, we > perhaps could do something along this line: > > * Pick a recent stable point that is an ancestor of all topics in > flight. Add the new coccinelle rule file, take "make coccicheck" > output and create a two-patch series like Philip suggested. Queue > the result in a topic branch B. > > * For each topic in flight T, make a trial merge of T into B, and > examine "make coccicheck" output. Any new breakages such a test > finds are new violations the topic T introduces. Discard the > result of the trial merge, and add one commit to topic T that > corrects the violations the topic introduced, and send that fixup > to the author of the topic for consideration when the topic is > rerolled (or if the topic is in 'next', acked to be queued on > top). Do not fix the violations that is corrected when branch B > was prepared above. > > As I assumed that applying the patches in this series would create > the branch B, and then I saw that the tip of 'seen' after merging > this topic still needed to have a lot more fixes according to "make > coccicheck", I got a (false) impression that there are too many new > violations from topics in flight, which was the primary source of my > negative reaction against potential code churn. If we try the above > exercise, perhaps there may not be too many topics that need fix-up > beyond what we fix in the branch B, and if that is the case, I would > not be so negative. So I tried that myself, and the topic branch B was fairly straightforward to create. We have ~60 topics in flight (not counting this one), and it turns out that there is no topic that introduces new code that fails the equals-null.cocci rule. IOW, the follow-up fixup per topic turns out to be an empty set. So, I'd probably use the [01/23] and then a single ~5k lines patch that was generated with equals-null.cocci rule as the branch B above, let it percolate down from 'seen' to 'next' to eventually 'master'. Thanks.
