Re: Replacing Link trailers

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Oct 16, 2025 at 07:54:01AM -0400, James Bottomley wrote:
> 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?

Where exactly would that be added?  Are you suggesting that git add a
new atom_type of ATOM_MESSAGEID or something like that?

If so, sure, that works for me, I just want a way to track back a commit
to a message somehow that does not require me to pick-and-choose when I
want to add that reference, as that increases the workload on
maintainers.  Be it a link: or a message-id, or something else that I
can "set and forget" in my git hooks and so can all other maintainers.

Then, sometime in the future, a user is happy that the maintainer "paid
the insurance bill" of adding that reference, so they can look up the
original commit as something went wrong.

Sounds like the networking maintainers also want it, as does drm.  I
think those are the two largest creators of commits in our tree these
days by far.  Luckily staging has died down so I'm no longer in that
category :)

thanks,

greg k-h




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
> 
>