Re: Replacing Link trailers

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2025-10-13 at 08:25 -0400, Mathieu Desnoyers wrote:
> On 2025-10-13 07:53, James Bottomley wrote:
> > There has been a lot of discussion on the tooling list about how
> > the loss of link trailers has updated both tooling and triaging
> > issues. Konstantin has proposed a tool to get around this, but
> > while that's in development, I propose a discussion about making
> > Link (or some alternative tag) into the pointer that would work for
> > everyone.
> 
> AFAIU. this use of Link trailer is used as a strategy to work around
> the lack of unique identifier in patch commit messages that
> identifies multiple revisions of a patch, for tracking by patch
> review tooling and facilitate digging through patch history.

Actually no.  Link merely linked the commit back to the original email.
There was a proposal, by Thomas Gleixner also to have back links in
cover letters, which some people do, that would allow recovery of the
whole email history, but absent that it goes back only to the last
iteration.  However, the last iteration is sufficient for the tools.

> I think it's important to spell out the problem this is trying to
> solve from the get go.
> 
> Based on prior email discussions I've seen, I don't think Linus is
> convinced that tagging commits with a unique identifier brings value,
> whereas people actively developing and using tools based on a
> workflow that relies on patch revision tracking see a lot of value
> in this.
> 
> Putting this in context may help listing the possible solutions that
> go beyond links and evaluate the best solution. For instance, gerrit
> uses change id tags such as:
> 
> Change-Id: I9bfbee7a3219c3f293cee2bafce7233ec34d3e84

Rally, no.  The point is not to track the patch across multiple changes
in git, but to track the email discussions.  Gerrit is git based so
there are multiple commits in the gerrit/github/git workflow where the
same patch appears with a different commit id.  In Linux we don't
really do this except in rebaseable trees we don't care about (and the
odd same patch different trees scenario) so it's definitely about
tracking emails not commits.

> to track the various revisions of a patch. Unlike "Link" tags, it is
> clear that it's only meant to be a unique identifier for the various
> revisions of a patch, and it's not meant to be used as a link.
> 
> AFAIU the use of "Link" tags for that purpose tried to achieve a
> similar goal, but ends up polluting the information seen by humans,
> which is an unwanted side-effect.
> 
> It's great to hear that Konstantin is working on this. I look forward
> to see what comes out of it.

That's b4 dig ... it's based on fuzzy matching of the patch-id
currently, I believe.

Regards,

James