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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2019-07-03 at 00:07 +0200, Thomas Gleixner wrote:
> On Tue, 2 Jul 2019, James Bottomley wrote:
> 
> > On Tue, 2019-07-02 at 09:30 -0700, Kees Cook wrote:
> > > On Tue, Jul 02, 2019 at 08:51:53AM -0700, James Bottomley wrote:
> > > > 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 this should be easy to implement in a general way. I
> > > suspect there wouldn't be much love for hard-coding the details,
> > > though, so maybe it would require per-developer git
> > > configuration. I imagine a general mapping would need to be:
> > > 
> > > list_email -> archive_url
> > > 
> > > i.e. if "$list_email" is in the To/Cc, then "git am" can easily
> > > insert the Message-Id into the "$archive_url". For example:
> > > 
> > > linux-kernel@vger.kernel.org -> https://lkml.kernel.org/r/%s
> > 
> > I don't want to admit to being the sucker who actually looking into
> > coding this today, so shall we just say I learned through
> > "contacts" that git already has this feature:
> > 
> > ---
> > commit a078f7321b02eb945b63804a80b0ba52c9da4ed3
> > Author: Paolo Bonzini <pbonzini@redhat.com>
> > Date:   Tue Nov 25 15:00:56 2014 +0100
> > 
> >     git-am: add --message-id/--no-message-id
> > ---
> > 
> > It's not quite as we would wish: it adds a 
> > 
> > Message-ID: <ID>
> > 
> > Tag to the commit.  For some reason its undocumented, but it's been
> > there since version 2.3.0.  I realise the format isn't what we've
> > been discussing, but if it's there we can use it ... and since it's
> > in a pretty early version we can all use it now.
> 
> Please no.
> 
> If we allow Message-ID just because git has that undocumented
> feature,

Actually, documentation was added in a later version, so in my 2.13 git
it's there.  It even has a config option to turn it on

am.messageid = 1

>  then we open the door for the next undocumented tag because XYZ has
> that other magic feature which creates 'This patch was sent with
> $Message-Id: <ID>'.

git is our upstream for version control and our upstream has already
had this as a feature since 2014.  Trying to go to upstream  5 years
later and ask them to change it is likely going to be a singularly
unsuccessful exercise, plus even in the unlikely event we can work out
how to do it compatibly and without causing confusion and upstream said
yes it would take another few years to propagate.

> We really don't want yet another version of tag for that purpose. The
> 'Link:' tag is documented and proven to be useful.

You were the one pushing this, do you really want to hold it up because
what's available isn't exactly what you want?

What's wrong with Kees' suggestion that we add a new config option to
determine how we display the tag?  The information is basically there
so a Message-Id: tag can be converted to any type of Link: tag you
like.

I'm going to be a lot more successful going to the git upstream and
saying we've already been using a Link tag for a while, so we'd like
your message-id to appear as a Link: for compatibility than I am going
to be to try to get them to add a Link: tag ...

James