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

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

On Tue, Sep 09, 2025 at 06:12:19PM -0700, dan.j.williams@intel.com wrote:
> Konstantin Ryabitsev wrote:

> > We can't control how the patches are generated by submitters. If someone
> > generates and sends them with --histogram, this won't work. Here's an example
> > right from your tree:

> Is this a matter of teach git send-email to generate a header, e.g.
> "X-Patch-ID:", for a given stable diff format convention? That lets
> submitters use any diff format they want, but the X-Patch-ID: is
> constant. Then "git show $diff_opts_convention $commit" becomes more
> reliable over time.

We can't rely on people using git send-email at all, and they might be
using an old version (eg, from their distro) even when thy do.

> It still does not help the problem of maintainers massaging patches on
> their way upstream, but patch.msgid.link does not help that either
> because that Link: is not the patch that was merged. So if you care
> about automated tooling being able to query lore for commits, the

That's not really what people are using these links for - if you have
the commit you don't need to go to the mailing list archive to get it.
You're more likely to be using them to find the relevant discussion, see
who was involved and possibly send some kind of followup (eg, to report
a regression in my case).  A link tag, especially one with a well
defined domain for the links, works fine in this sort of application
since it's pointing at the last point the thing was on the list
regardless of how poorly what's made it into git corresponds to what was
posted.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]