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

[Randy Dunlap <rdunlap@infradead.org>]

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::

	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.

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

-- 
~Randy