Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits

Joel Fernandes
2019-08-27T21:35:01Z

On Tue, Aug 27, 2019 at 3:53 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Aug 27, 2019 at 02:55:28PM -0400, Konstantin Ryabitsev wrote:
> > On Tue, 27 Aug 2019 at 11:33, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > > Link: https://lkml.kernel.org/$Message-ID
> > > >
> > > > then you have your UUID tag. The tip bot sends you a reply based on that
> > > > tag and I know you got some of them already.
> > >
> > > I'm using:
> > > Link: https://lore.kernel.org/r/$message-id
> > >
> > > should we standardize on the lkml one instead as it's shorter? The lore
> > > one handles any message id that is on any mailing list it handles, is
> > > the lkml one the same?
> >
> > It's the exact same system and the /r/ is always required. I prefer
> > lore.kernel.org because it doesn't imply that the message is going to
> > be on the LKML (i.e. it can be on a list that isn't even hosted on
> > vger.kernel.org).
> >
> > So, my recommendation is Link: https://lore.kernel.org/r/$message-id
>
> Great, will stick with that one, thanks.

I am thinking of how to make this automagic and useful for me. My plan
is (and ymmv):

When I write a patch, have a git hook generate "Message-Id" in my
patch changelog itself when it is written using Greg/Andrew's
make_message_id. This Message-Id is not the final message-id and is
just for reference purposes for later processing. Then when sending
it, after git format-patch I will do a few things:
(a) Consult the archive to check the highest value of N for which
Message-Id-<N> does not exist
(b) Add Message-Id: Message-Id-<N> to the patch header so git
send-email uses this as the Message-Id-<N>
(c) Add this Message-Id-<N> as a Link: to the changelog; Possibly
removing Message-Id<N-1> link.
(d) Remove the original "Message-Id" without the -<N> from the
changelog since it has no purpose.
(e) Send the patch

This will automatically link all the previous revisions of a patch
vN..vN-1...v1...0. And also does not need any manual labor - which is
one of the main selling points AIUI of Google's git hooks for using
"Change-Id:". Also works for Doug's use case and for people wanting
to have a Link: tag.

Such a git hook can then be provided to the kernel community to better
automate their flow of Link: generation. Although the steps (a) to (e)
may require additional tooling and changing of the local git tree at
the time a patch is submitted - which is Ok for my flow but not sure
if it would work for everyone.

Thoughts?

thanks,

- Joel