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

[Jakub Kicinski <kuba@kernel.org>]

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