Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Sep 09, 2025 at 08:35:18AM -0600, Jens Axboe wrote:
> On 9/9/25 8:18 AM, Jakub Kicinski wrote:
> > On Tue, 09 Sep 2025 15:17:15 +0200 Rafael J. Wysocki wrote:
> >>>> We do support this usage using `b4 shazam -M` -- it's the functional
> >>>> equivalent of applying a pull request and will use the cover letter contents
> >>>> as the initial source of the merge commit message. I do encourage people to
> >>>> use this more than just a linear `git am` for series, for a number of reasons:  
> >>>
> >>> For me, as a subsystem downstream person the 'mindless' patch.msgid.link
> >>> saves me time when I need to report a regression, or validate which
> >>> version of a patch was pulled from a list when curating a long-running
> >>> topic in a staging tree. I do make sure to put actual discussion
> >>> references outside the patch.msgid.link namespace and hope that others
> >>> continue to use this helpful breadcrumb.  
> >>
> >> Same here.
> >>
> >> Every time one needs to connect a git commit with a patch that it has come from,
> >> the presence of patch.msgid.link saves a search of a mailing list archive (if
> >> all goes well, or more searches otherwise).
> >>
> >> On a global scale, that's quite a number of saved mailing list archive searches.
> > 
> > +1 FWIW. I also started slapping the links on all patches in a series,
> > even if we apply with a merge commit. I don't know of a good way with
> > git to "get to the first parent merge" so scanning the history to find
> > the link in the cover letter was annoying me :(
> 
> Like I've tried to argue, I find them useful too. But after this whole
> mess of a thread, I killed -l from my scripts. I do think it's a mistake
> and it seems like the only reason to remove them is that Linus expects
> to find something at the end of the link rainbow and is often
> disappointed, and that annoys him enough to rant about it.
> 
> I know some folks downstream of me on the io_uring side find them useful
> too, because they've asked me several times to please remember to ensure
> my own self-applied patches have the link as well. For those, I tend to
> pick or add them locally rather than use b4 for it, which is why they've
> never had links.
> 
> As far as I can tell, only two things have been established here:
> 
> 1) Linus hates the Link tags, except if they have extra information
> 2) Lots of other folks find them useful

I too find them useful, especially when doing stable backport work as
it's a link to the thread of multiple commits, so I can see what is, and
is not, tagged for stable, and the proper ordering of the commits.

So I'm going to want to keep leaving them on, they work well for those
that have to spelunk into our git branches all the time.

thanks,

greg k-h