On Wed, Aug 27, 2025 at 04:40:58PM -0700, Linus Torvalds wrote: > On Wed, 27 Aug 2025 at 15:49, Konstantin Ryabitsev > <konstantin@xxxxxxxxxxxxxxxxxxx> wrote: > > > > I have recommended that Link: trailers indicating the provenance of the series > > should use a dedicated domain name: patch.msgid.link. This should clearly > > indicate to you that following this link will take you to the original > > submission, not to any other discussion. > > That doesn't fix anything. It only reinforces the basic stupidity of > marking the WRONG DIRECTION. > > The fact is, YOU CANNOT SANELY MARK THE COMMIT. Dammit, why do people > ignore this *fundamental* issue? You literally cannot add information > to the commit that doesn't exist yet, and the threads that refer to > bugs etc quite fundamentally WILL NOT EXIST YET when the commit is > posted. I'm not sure what you mean. The Link: trailer is added when the maintainer pulls in the series into their tree. It's not put there by the submitter. The maintainer marks a reliable mapping of "this commit came from this thread" and we the use this info for multiple purposes: 1. letting the submitter know when their series is accepted into the maintainer's tree 2. marking the series as "mainlined" when we find that commit in your tree 3. it reliably marks provenance for tools like cregit, which largely have to guess this info It serves a real purpose. > It's the *message* that should be indexed and marked, not the commit. We cannot *reliably* map commits to patches. A commit can be represented as any number of patches, all resulting in different patch-id's -- it can be generated with a different number of context lines, with a different patch algorithm, it could have been rebased, etc. Maintainers do edit patches they receive, including the subject lines. I know, because attempting to automate things without a provenance Link: results in false-positives for projects like netdev. > Really. The only valid link is a link to *pre-existing* discussion, > not to some stupid "this is where I posted this patch", which is > entirely and utterly immaterial. > > And dammit, lore could do this. Here's one suggested model that at > least gets the direction of indexing right (I'm not claiming it's the > only model, or the best model, but it sure as hell beats getting the > fundamentals completely wrong): > > (a) messages with patches can be indexed by the patch-id of said patch They already do, it's been there for a long time now. Here's a random one: https://lore.kernel.org/lkml/?q=patchid%3A09b124c33929efcffe0ce8df0a805f54d5962f60 > This might well be useful in its own right ("search for this patch"), > and would be good for the series where the same patch ends up being > re-posted because the whole series was re-posted. This is how we are able to pull in trailers sent to previous series, if the patch-id hasn't changed. > IOW, just that trivial thing would already allow the lore web > interface to link to "this patch has been posted before", which is > useful information on its own, totally aside from any future > archeology. > > But it's not the end goal, it's only a small step to *get* to the end goal: > > (b) messages that mention a commit ID (or a subject line) could then > have referrals to the patch-id of said commit. To reiterate, a commit is not a patch, so *we cannot reliably arrive from a commit to always the same patch-id*. We've discovered it the hard way when you recommended that people send you patches with --histogram and we suddenly could no longer reliably map commits to patches, because on our end we generated patches with the default (myers) and they did not match the patches generated with --histogram, so our automation broke. This is what I am trying to convey -- commits don't reliably map to patches, because the same commit can generate any number of perfectly valid patches, all with different patch-id's. -K
