Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Patch version changes in commit logs?

[Shuah Khan <skhan@linuxfoundation.org>]

On 7/2/19 9:51 AM, James Bottomley wrote:
> On Tue, 2019-07-02 at 09:39 -0600, Shuah Khan wrote:
>> On 7/2/19 9:18 AM, James Bottomley wrote:
>>> On Tue, 2019-07-02 at 08:10 -0700, James Bottomley wrote:
>>>> On Tue, 2019-07-02 at 16:49 +0200, Thomas Gleixner wrote:
>>>
>>> [...]
>>>>> People who use the link tag today have their homebrewn scripts
>>>>> to add them automatically and it shouldn't be rocket science to
>>>>> add that to git, patchwork whatever.
>>>>
>>>> So if we find a way of automating this globally, I'm completely
>>>> happy. However, I would also note that whatever script does this
>>>> could likely also be run by you after the fact to generate the
>>>> back link, so foolproof automation also lessens the need to make
>>>> this a mandatory commit tag.
>>>
>>> Just on this one, it looks like getting git to archive the msgid of
>>> the patch commit would assist any script that goes off and tries to
>>> find patch series and its precursors in the archives, so perhaps
>>> adding that would be the actionable change in all of this?
>>>
>>
>> Looks like two things are emerging from my original thread that aimed
>> to get clarification on including "Patch revision information" in
>> commit logs.
>>
>> 1. Judiciously including information from the "Patch revision info."
>>      in the commit log could be valuable. Don't just bloat the commit
>>      log with trivial change history. This is part of patch review
>>      process and will not require any scripting. Maybe an update to
>>      the patch submit guidelines documents.
> 
> Agree, as long as it's what Thomas and I have been discussing: namely
> keeping the version information below the --- permanent history cutoff,
> so it's visible to reviewers but won't become part of the permanent
> patch history when the patch is committed to git.
> 

Yes that is what I have in mind. Below the -- permanent history cutoff
to help reviewers.

> I think the bit we're still arguing about is the link to prior series
> as part of this below the line version history.  I agree it's useful,
> but I also think it would be a burden to enforce for every patch
> series.
> 
>> 2. Archiving msgid of the patch commit for reference. This one would
>>      require some scripting to make it easier for maintainers.
> 
> Yes, I think we all agree on this.  The real question is how.  If we
> make git do it, I think trivially Message-Id: can become part of the
> optional metadata.  Or we could all use commit hooks that add a link
> tag.  Personally I prefer the former because it would be universally
> done with no effort but I recognise it would take time to get the
> ecosystem change to propagate.
> 

I think having git do it is better way to go. It becomes part of git
work-flow. There is no need to educate developers yet another script
and process.

thanks,
-- Shuah