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

From: Doug Anderson <dianders@chromium.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Joel Fernandes <joelaf@google.com>,
	Barret Rhoden <brho@google.com>,
	ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jonathan Nieder <jrn@google.com>,
	Tomasz Figa <tfiga@chromium.org>,
	Han-Wen Nienhuys <hanwen@google.com>,
	Theodore Tso <tytso@google.com>,
	David Rientjes <rientjes@google.com>,
	Dmitry Torokhov <dtor@chromium.org>,
	Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [Ksummit-discuss] Allowing something Change-Id (or something like it) in kernel commits
Date: Fri, 23 Aug 2019 10:50:26 -0700	[thread overview]
Message-ID: <CAD=FV=VUm+6G9HFX0E_e=fnun+xs=a-M48krRWUdOgi6JzQY0Q@mail.gmail.com> (raw)
In-Reply-To: <20190823165018.GB19727@lunn.ch>

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