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

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Tue, Sep 09, 2025 at 10:25:11AM -0700, dan.j.williams@intel.com wrote:
> Linus Torvalds wrote:
> > On Tue, 9 Sept 2025 at 07:50, Jens Axboe <axboe@kernel.dk> wrote:
> > >
> > > I think we all know the answer to that one - it would've been EXACTLY
> > > the same outcome. Not to put words in Linus' mouth, but it's not the
> > > name of the tag that he finds repulsive, it's the very fact that a link
> > > is there and it isn't useful _to him_.
> > 
> [..]
> > Honestly people. Stop with the garbage already, and admit that your
> > links were just worthless noise.
> > 
> > And if you have some workflow that used them, maybe we can really add
> > scripting for those kinds of one-liners.
> > 
> > And maybe lore could even have particular indexing for the data you
> > are interested in if that helps.
> > 
> > In my experience, Konstantin has been very responsive when people have
> > asked for those kinds of things (both b4 and lore).
> 
> Hmm, good point. Lore does have patchid indexing. This needs some more
> cleanup but could replace my usage of patch.msgid.link.
> 
> firefox http://lore.kernel.org/all/?q=patchid%3A$(awk '{ print $1 }' <<< $(git patch-id --stable <<< $(git show $commit)))
> 
> Now, it does drop one useful feature that you know apriori that the
> maintainer did not commit a private version of a patch. However it
> should work in most cases.

It doesn't work reliably. Often enough maintainers massage the patch
a bit while applying to fix minor nits and patch-id will be different.
Here is just one such example:
c11f34e30088 ("bpf: Make update_prog_stats() always_inline")
and the commit includes the lore link to the original patch and
the comment how I tweaked it while applying:
https://lore.kernel.org/all/20250621045501.101187-1-dongml2@chinatelecom.cn/
git patch-id cannot find it:
https://lore.kernel.org/all/?q=patchid%3Afa0565c81e53682a83f4a0e6699c5664c53cda27

Linus's q=$(git rev-parse e9eaca6bf69d^2) trick worked because pr-tracker-bot
replied. That bot is not reliable either. Often enough we mark patches
in patchwork manually, because tracker missed them.

Really, there is no way for automation to detect the connection between
commit that landed in the tree and the original email unless git hooks
add something to the commit. Right now Link tag is that connection.