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

[Doug Anderson <dianders@chromium.org>]

Hi,

On Fri, Aug 23, 2019 at 9:50 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > 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?

Yes, if we can't agree to have Change-Id part of the commit that lands
as part of the kernel, then trying to get some smarts into
git-send-email and git-format-patch would definitely be the way to go.

-Doug