On Fri, Aug 29, 2025 at 08:30:33AM -0400, Theodore Ts'o wrote: > So here's a set of feature requests for b4. > > (a) It would be cool(tm), if there was a way for b4 to automatically > detect whether or not there was a reply to a patch at the time that > "b4 am" is run; if there is, to include the patch series. If there > isn't an e-mail reply, skip the the Link: trailer. I'm afraid this would mostly breed confusion. > (b) In the case of a patch series, it would be useful to include some > kind of trailer indicating that a group of patches are logically > grouped together (maybe a patch-series: that has the message id to > the the series header, or the first patch if there is no patch #0) > --- because one of the other ways that I figure out that a series > of commits are part of a patch series is by looking at the Link: > field since if the messages are generated using "git send-email" > it's usually obvious from the message id. This has also come up > from some of the folks who want this for their web-based review > systems. I don't care about that, but if it solves multiple use > cases at once, that's great. This is already in place with the change-id trailer (and the corresponding X-Change-ID email header). However, only b4 puts those in. Series prepared and sent with git-send-email don't have any identifier like that. > (c) Include a link tag to the patch series description e-mail message > (if present) in the first commit of the patch series so it's > possible to read the patch #0 description of the patch series, > since otherwise this can get be hard to find in the git history. We're talking about the lore.kernel.org web interface? > (d) For bonus points, if there is a way to determine a link to the > previous versions of the patch series, it would be useful for to > incude link: tags to previous versions of the patch if and only if > there were e-mail comments to say, the v5, v12, and v27 versions > of the patch. Again, are we talking in the context of the lore.kernel.org web interface? The initial discussion about Link: tags was about them being present in git commits. > (e) If there is some way we can easily capture lore.kernel.org URL for > the vN-1 version of the patch series in the vN commit description > header, in "b4 prep" that would be *excellent*. I don't think it > can do this today, but if it can, can we make sure it's defaulted > to on, and then we should **really** market the heck out of b4 > prep? You can do this for any b4-prep sent series by just searching for the change-id string. E.g.: https://lore.kernel.org/lkml/?q=20241018-pmu_event_info-986e21ce6bd3 `b4 prep` is used quite extensively these days, but it's far from being predominant. > The bottom line is I'd love to make Linus less cranky; but I'd also love > it if I didn't have to do the extra work by hand. :-) Because if I do > have to do it by hand, I will probably screw up, and my preference has > been to err on the side of having the link, so it's there when I'm > having to code code archeology --- even if most of the time it's not > strictly speaking necessary. This doesn't ultimately solve the problem that we're butting heads about -- that it's impossible to reliably match a commit to its provenance. Using Link: trailers indicating where the patch came from is the only reliable mechanism we have thus far, because it establishes this relationship unequivocally. However, these links annoy Linus, who would like this to be automated in some other way behind the scenes. I'd love to be able to do so, but short of running some kind of "provenance transparency log" of curated commit -> message-id mappings, I don't see how it's possible. -K
