On Monday, September 8, 2025 10:11:00 PM CEST [email protected] wrote: > Konstantin Ryabitsev wrote: > > (Changing the subject and aiming this at workflows.) > > > > On Fri, Sep 05, 2025 at 11:06:01AM -0700, Linus Torvalds wrote: > > > On Fri, 5 Sept 2025 at 10:45, Konstantin Ryabitsev > > > <[email protected]> wrote: > > > > > > > > Do you just want this to become a no-op, or will it be better if it's > > > > used > > > > only with the patch.msgid.link domain namespace to clearly indicate > > > > that it's > > > > just a provenance link? > > > > > > So I wish it at least had some way to discourage the normal mindless > > > use - and in a perfect world that there was some more useful model for > > > adding links automatically. > > > > > > For example, I feel like for the cover letter of a multi-commit > > > series, the link to the patch series submission is potentially more > > > useful - and likely much less annoying - because it would go into the > > > merge message, not individual commits. > > > > 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. Cheers, Rafael
