Re: Replacing Link trailers

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

On Thu, 2025-10-16 at 08:57 +0200, Greg KH wrote:
> On Wed, Oct 15, 2025 at 12:17:27PM -0700, Linus Torvalds wrote:
> > On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > > 
> > > (The above script is "tested" in that I verified that yes
> > 
> > .. premature 'hit send' situation. That should have said
> > 
> >  ..that yes] I verified that it superficially works, but didn't do
> > anything exhaustive.
> > 
> > It was obviously meant as a "look, you can do things like this",
> > not as a real fully fleshed out solution.
> 
> So, to summarize all of this, you are suggesting that maintainers:
> 	- don't automatically include Link: tags when they don't
> touch a
> 	  patch and apply it directly from the email as `b4 dig`
> will be
> 	  able to find the patch.
> 	- if a maintainer does change a patch, add the Link: tag so
> that
> 	  people can find the original patch when looking it up
> later.
> 
> Is that correct?
> 
> If so, ugh, that just raised the workload of all of us maintainers as
> now we have to remember to do that second step manually (or through
> the new git hook, which will NOT work without a network connection so
> no applying patches from planes or trains).

I agree with all the complexity.  So why don't we simply have git am
add message-id to the commit header if it exists in the patch?  That
way every b4 generated commit will have a message-id header.  No-one
will ever see it unless they ask for the --pretty=raw (which is what
tools can do, so they'll all just work) and it is completely mindless
so everyone always knows what it points to if they want to dig it out.
b4 dig can even use it as the starting point to find the email.

Bonus: everyone is forced to use it (because it's built in to git) and
we always know exactly what it means: no debate about what the target
of the link should be.

Regards,

James