Re: linux-next: Fixes tag needs some work in the jc_docs tree

[James Clark]

On 07/01/2022 16:19, Randy Dunlap wrote:
> Hi James,
> 
> First of all, don't always believe what checkpatch says.
> Just take it as a hint.
> 
> On 1/7/22 02:25, James Clark wrote:
>>
>>
>> On 06/01/2022 23:36, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> In commit
>>>
>>>   e94f43ea200a ("docs: automarkup.py: Fix invalid HTML link output and broken URI fragments")
>>>
>>> Fixes tag
>>>
>>>   Fixes: d18b01789ae5 ("docs: Add automatic cross-reference for
>>>
>>> has these problem(s):
>>>
>>>   - Subject has leading but no trailing parentheses
>>>   - Subject has leading but no trailing quotes
>>
>> Hi Stephen,
>>
>> Which validator are you using for this output? checkpatch.pl has a validator for commit references
>> and it actually complains _more_ if it's not wrapped at 75 chars. At least for ones in the
>> body of the commit rather than the fixes reference. Which is a bit confusing if there is
>> a difference in the rule.
>>
>>>
>>> Please do not split Fixes tags across more than one line.
>>>
>>
>> Is this just for the fixes tag and not for the one in the body? Would you consider adding
>> this check to checkpatch.pl and submitting-patches.rst as I don't see that rule mentioned there.
> 
> submitting-patches.rst says:
> 
> If your patch fixes a bug in a specific commit, e.g. you found an issue using
> ``git bisect``, please use the 'Fixes:' tag with the first 12 characters of
> the SHA-1 ID, and the one line summary.  Do not split the tag across multiple
> lines, tags are exempt from the "wrap at 75 columns" rule in order to simplify
> parsing scripts.  For example::

Thanks I missed that bit.
> 
> 	Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the number of pages it actually freed")
> 
> 
> Yes, checkpatch warns about that. Just ignore it.

I looked into adding a line break warning in checkpatch for 'Fixes:' but it's not easy because it seems like
the fixes field is more permissive than the other one:

	o Fixes: style doesn't require ("<commit_description>")
	parentheses and double quotes like other uses of
	git commit ID and description.

> 
>> @Jonathan, I'm happy to resubmit with the changes, but it might be easier if you just
>> make the fix in place.
>>
>> Thanks
>> James
>