I think there may be 2 schools of thought on style fixes. Imagine up front creating a commit before changing code in files that fixes ONLY all of the style issues. Essentially this commit should contain only white space changes. If the commit is marked as such. It can be mechanically validated by comparing the binary result of the build Before & After the application Of the style commit.
The next commit in the set would have the actual changes to the code. This is where experts in the subject matter can add value reviewing it. Monster PRs ( Lots of files changed with lots of lines of changed) are very difficult to review. If the majority of the changes are style only. The above method Reduces the possibility of error While minimizing the burden on subject matter experts. On Tue, Dec 24, 2019, 6:18 PM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > On Wed, Dec 25, 2019 at 6:52 AM Gregory Nutt <spudan...@gmail.com> wrote: > > > > > > > If they are related / dependent on each other, then I think those > > > kinds of patchsets should be encapsulated in one branch. > > > > The need to be applied and committed in sequence. Sometimes the final > > patch is the one that fixes the coding style. This is inherently very > > manual. > > > > The style fix should be in one patch not the separated patch. If the > new code has the style problem, contributor should fix it and resend > PR again. > If the code base has the style issue, we should send new PR to fix the > whole style issue. > > Of course, some committer may want to help fix the issue. It's fine, > but the new change still need pass all check and reviewed by other > committer before merge. > Nobody has the right bypass the criticia we will define in the > workflow document and merge the patch(even it just fix the style > issue) directly. >
