On Tue, May 10, 2022 at 12:32 AM Jonathan Corbet <corbet@xxxxxxx> wrote: > > Trying to take a closer look this time... > > I foresee merge conflicts, but so it goes. Trying to split this apart > would not make a lot of sense. Is there a big change coming to docs? (there are not conflicts in linux-next within the docs). Or what do you mean? > Please use normal tables rather than list-table; this kind of thing is > really unreadable in the source form. Will do! > I foresee disagreements over coding style conventions in the > future... I don't plan to be part of that conversation :) Do you mean with the tool settings? I guess we may get some proposals about tweaking them, yeah, but one reason to stick to the defaults is to avoid that! :) If you mean enforcing `rustfmt`, please see below. > I will ask whether we want this, though. Why would anybody want to > mass-reformat the entire body of kernel code? This seems like something > that would generate an endless stream of "helpful" patches and a lot of > churn. So the idea is that, since everything is already formatted, the output of this is empty (in mainline), like Gaelan/Josh mentioned. Thus nobody should be sending any formatting patches since there is nothing to change. Now, for those developing and not running `rustfmt` automatically in some way (e.g. in their editors), it can be useful to run it before submitting the patches: the output should only show changes to whatever you changed since everything else should be already formatted. Of course, as soon as others start submitting patches independently, mistakes may slip through, but we are enforcing this in our CI (and it could be done more centrally), so we should notice quickly. There could be, of course, bugs in the tool; and there are a few situations where the tool may not guarantee formatting stability, but hopefully those are rare and small enough so that we can keep enforcing this. I think it is worth trying. Cheers, Miguel
