Re: Replacing Link trailers

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

On Thu, 2025-10-16 at 14:18 +0200, Greg KH wrote:
> 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?

Yes, I think so ... just looking at constructing a patch now.
Regardless of the outcome of this debate it seems like a reasonable
(and not kernel specific) feature to add to git.

I'm also looking in to adding a commit hook that might do the same
thing for the interim, but I don't think hooks can add headers (still
searching though).

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

I get that. I actually think this debate should be split into two
pieces:

   1. What completely automated thing do we need to help tools with
      tracking.  I think the message-id header would do that
   2. What mindful thing could maintainers add to a commit to give
      useful background information?

I think a lot of people want the former but Linus is asking for the
latter and Link: has previously tried to serve both purposes which lead
to the current dispute. I'm hoping splitting the discussion will
produce something better on both fronts.

So to reiterate this proposal is only for 1. we should still debate
what would be useful to add for more information that humans can
consume and when should it be added.

Regards,

James