Il giorno lun 2 mag 2022 alle ore 01:14 Junio C Hamano <gitster@xxxxxxxxx> ha scritto: > > Elia Pinto <gitter.spiros@xxxxxxxxx> writes: > > >> What I found curious is that the result of applying these patches to > >> v2.36.0 and running coccicheck reveals that we are not making the > >> codebase clean wrt this new coccinelle rule. > >> > > It is possible, I did not use coccicheck to apply the semantic patch > > (on next) but i use a my script which I think is slightly more > > efficient but perhaps it is not so correct. Anyway, given the > > discussion that has taken place so far, what do you think is best for > > me to do? Do a reroll (perhaps with only 2 patches in total ) or wait > > for the "right" moment in the future as foreseen by the Documentation > > and dedicate the time to more useful contributions for git? Thank you > > all for the review > > Hmph. Even if these patches were created by coccicheck we should > sanity check them to make sure we are not applying some stupid and > obvious mistakes, but if they were created by an ad-hoc tool, it > means we would need to check a lot more careful than a patch that > was done with a known tool with a clear rule (which is what running > "make coccicheck" with your new rule file would have given us). > > 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. > > Thanks. Thank you but it seems like a very heavy work for something that had to be much simpler. IMHO my contribution, if deemed useful, ends with the patch that adds ONLY the cocci script, which can solve a style problem identified by the documentation. And it sure works, if applied. But it is not necessarily the case that there must be to the same time a patch series that actually applies the script to the git codebase, in any development branch. This can be done at the most opportune moment by anyone who wishes it, from my POV. Again, thanks you all Best Regards > > >
