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

Andrew Lunn
2019-08-23T16:50:22Z

> 1. Make it allowed or suggested to put a well-formed (machine
> parseable) Change-Id "after the cut" on mailing list posts, which
> would allow you to associate v1, v2, and v3.
>
> 2. Add "Link://lkml.kernel.org/r/$MSGID_PER_PATCH" to landed patches,
> which would allow you to recover the Change-Id even after a patch
> lands.
>
> ...then I will be happy (ish). The biggest downside I see here is
> that it is much less likely that random committers out there will get
> this right. The way committers naturally have the same Change-Id from
> v1 to v2 to v3 is because it's part of the commit message and when you
> amend to a previous change it stays there. That means that these
> people will need to remember to move the Change-Id to "after the cut"
> unless we teach git-send-email to do this for you (though I guess
> maybe we could do that?).

To make this reliable, we really need git to be doing the work. We
should also think about the typical developer workflow.

To create a v1 of a patch, i do a git commit. To make a v2, i'm likely
to be using git rebase -i; git commit --am.

So why not have the initial git commit allocate the UUID. git commit
--am leaves the UUID alone. git-format-patch can then put the UUID
after the ---. Can git-send-email generate the MSGID from the UUID?

Andrew