On Wed, Jul 20, 2022 at 03:21:44PM -0400, Konstantin Ryabitsev wrote: > On Mon, Jul 18, 2022 at 02:24:07PM -0700, Glen Choo wrote: > > > I just started working on this for b4, with the notable difference that the > > > change-id trailer is used in the cover letter instead of in individual > > > commits, which moves the concept of "change" from a single commit to a series > > > of commits. IMO, it's much more useful in that scope, because as series are > > > reviewed and iterated, individual patches can get squashed, split up or > > > otherwise transformed. > > > > My 2 cents, since I used to use Gerrit a lot :) > > > > I find persistent per-commit ids really useful, even when patches get > > moved around. E.g. Gerrit can show and diff previous versions of the > > patch, which makes it really easy to tell how the patch has evolved > > over time. > > The kernel community has repeatedly rejected per-patch Change-id trailers > because they carry no meaningful information outside of the gerrit system on > which they were created. Seeing a Change-Id trailer in a commit tells you > nothing about the history of that commit unless you know the gerrit system on Unless you happen to see another patch with the same ID, and for that to happen the ID needs to be generated when the commit is created (not when it's uploaded to gerrit or sent to a mailing list), and preserved by default in all processing of the commit. Then you can actually track the commit as it evolves in tools like patchwork, in theory. Thanks Michal
