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

Joel Fernandes
2019-08-23T19:15:51Z

On Fri, Aug 23, 2019 at 3:08 PM Joel Fernandes <joelaf@google.com> wrote:
>
> On Fri, Aug 23, 2019 at 2:00 PM Doug Anderson <dianders@chromium.org> wrote:
> [snip]
> > > On Fri, Aug 23, 2019 at 12:45 PM Doug Anderson <dianders@chromium.org> wrote:
> > > [snip]
> > > > Sure, if a given patch in the series is totally wrong and I re-write
> > > > it (but still want the re-write to be considered a new version of the
> > > > previous patch) then I have to manually copy the Change-Id for a
> > > > gerrit upload. ...but I'd also be OK if people just get a new
> > > > Change-Id in this case.
> > >
> > > Sometimes it is not "totally wrong" but just "done in a different
> > > away" and is a new series. This happens a lot since upstream
> > > development can be evolutionary. So your v1 may look nothing like v2
> > > and is a whole new series. Yet the history linking the 2 series is
> > > important. And no amount of automated commit ID generation can link
> > > them. This is the scenario I was talking about. I know the git hook
> > > works, but sometimes the Change-Id has to be manually copied. That's
> > > not automatable. May be we are slightly on different tracks, but this
> > > is the scenario that would be useful to trace IMO.
> >
> > Agreed that it would be useful and (personally) I'd do it. Maybe
> > others who are used to the gerrit workflow would also do it. ...but
> > what I like is that the fallback for those that don't try to hard
> > isn't that terrible. Yes they'd end up with a new Change-Id in some
> > cases, but presumably it still wouldn't be that hard for tools to help
> > you. Namely, if you have a series:
> >
> > Patch v1 1/3 - Add a frob - Change-Id A
> > Patch v1 2/3 - Add a larb - Change-Id B
> > Patch v1 3/3 - Use the frob to tweak the larb - Change-Id C
> >
> > ...and you decide that you should be tweaking a sneech instead of a
> > larb, you might end up with this if someone isn't careful to copy
> > Change-Ids and their workflow is to throw away the old patch #2 and #3
> > instead of amending.
> >
> > Patch v2 1/3 - Add a frob - Change-Id A
> > Patch v2 2/3 - Add a sneech - Change-Id D
> > Patch v2 3/3 - Use the frob to tweak the sneech - Change-Id E
> >
> > So you can't find v1 of patch #2 directly from v2 of patch #2.
> > ...but, a good tool could still help you here. It would see that at
> > least one patch in this series had the same Change-Id and it should
> > help you find the whole v1 series.
> >
> > If all 3 patches were all totally new and lost Change IDs then I guess
> > you're SOL, but maybe in that case it really should be considered a
> > new series anyway?
>
> Maybe it should be. It is hard to generalize it to work all the time.
> But I agree with you the above flow is better than nothing.
>
> It does seem people need more convincing here though, that inserting a
> unique ID into a commit message is acceptable.

Just to clarify, here I meant "inserting of something other than a
message ID" into the commit message.

>
> Another thing that could be done is, have the git hook insert the

And, here I meant have git-send-email or the patch sending program
insert the unique ID into the discardable part.

In my flow, I have scripts that remove metadata from my commit message
and insert them into the discardable part of the patch already which I
use for "additional notes". I am not sure what it would take to have
people use such scripts...

> whatever-ID into the discardable part of the patch. The archive will
> then have it even if the commit doesn't. Then something email2git or
> patchwork can connect different patches in the archive with a
> particular commit. I think Thomas Gleixner or someone else also
> proposed something similar in this thread. What's wrong with that
> idea?

thanks,
- Joel