Fam Zheng <f...@redhat.com> writes: > On Fri, 01/05 11:49, Alex Bennée wrote: >> >> Fam Zheng <f...@redhat.com> writes: >> >> > On Wed, 01/03 15:54, Michael Clark wrote: >> >> On Wed, Jan 3, 2018 at 3:41 PM, Fam Zheng <f...@redhat.com> wrote: >> >> >> >> > On Wed, 01/03 15:00, Michael Clark wrote: >> >> > > So it's essentially one error, the single line case pattern for >> >> > > table-driven decode which flags for long lines and asks to separate >> >> > > break >> >> > > onto its own line. >> <snip> >> >> > Thanks for taking a look! Practically, consistency with the rest of the >> >> > code and >> >> > human judgements (comments, explanation in replies etc.) often override >> >> > the >> >> > checkpatch complaints. Checkpatch is not always right. >> <snip> >> >> Fam, >> >> I wonder is there anyway we could signal to patchew that there are some >> acknowledged and approved coding style variances in the patch? Would >> something like: >> >> CodingStyleExceptions: 12 >> >> Be too polluting to the commit messages? Or perhaps something that can >> skip individual tests on a given run: >> >> CheckpatchFlags: --ignore-long-lines > > It sounds feasible. Putting these flags after a --- line will keep commit > message clean. > > OTOH I think we should spend effort on patching checkpatch.pl to > implement this.
I guess your right, given checkpatch is going to ingest the patch anyway. > > Fam -- Alex Bennée
