On 09/07/2015 01:05 PM, Markus Armbruster wrote:
> Paolo Bonzini <pbonz...@redhat.com> writes:
>
>> On 07/09/2015 17:23, Markus Armbruster wrote:
>>>> Apart from copy-n-pasting, there is also the problem that you can run
>>>> "checkpatch.pl -f" on a whole file ... it would also be ugly to suddenly
>>>> have (much) more warnings here.
>>>
>>> Feature. If you run checkpatch on a whole file, you obviously do it to
>>> find its ugly spots. Lines longer than 76 characters qualify.
>>
>> Based on the statistics, half of QEMU's files has at least one 76-79
>> character line. The noise from checkpatch.pl -f is actually a worse
>> thing than the cut-and-paste, but that's something that can be fixed in
>> other ways (e.g. different strictness for checkpatch.pl vs.
>> checkpatch.pl -f).
>
> Yup.
>
>> That said, and even though Thomas obviously hasn't read the previous
>> discussion, :) I do believe that 76 characters is too strict a limit.
>
> It's not a strict limit, it's a warning. The strict limit is 90.
>
The problem is that checkpatch returns non-zero for warnings, so this
interrupts my workflow; this means that many of my "patch testing"
scripts will now "fail" due to the shortened limit.
Unless there are documented error codes for checkpatch -- e.g. {0: fine,
1: warnings, 2: errors, 3+: script-errors }
I could then update my scripts to tolerate warnings, but this still
seems like a pain to me.
>> 76 would be great (two levels of email quoting are what you get 99% of
>> the time), and 78 would be nice, but I believe 79 provides the biggest
>> bang for the buck.
>
> 78 gives one level of quoting, and two-way diffs.
>
--
—js
