Re: Feature request: provide a persistent IDs on a commit

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Jul 20, 2022, 19:21 UTC
Message-ID: <20220720192144.mxdemgcdjxb2klgl@nitro.local>
In-Reply-To: <kl6lo7xmt8qw.fsf@chooglen-macbookpro.roam.corp.google.com>

On Mon, Jul 18, 2022 at 02:24:07PM -0700, Glen Choo wrote:

Show 13 quoted lines

> > 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 which this patch was reviewed (and have access to it, which is not a given). This is not as opaque as it used to be now that Gerrit provided ability to clone the underlying notedb, but this still fails on commits that were contributed to an upstream that doesn't use Gerrit.

The current recommended strategy for the kernel is to put any historical information (including any links to archival sites, etc) into the merge commit and only keep chain-of-custody and code-review trailers in actual code commits. For this reason, I opted to use change-ids in the cover letter only.

-Konstantin