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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, 6 Sept 2025 at 11:50, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> The primary consumer of this are the CI systems, though, like those that plug
> into patchwork

Yes, for a CI, it makes sense to try to have a fixed base, if such a
base exists.

But for that case, when a base exists and is published, why aren't
those people and tools *actually* using git then? That gets rid of all
the strangeness - and inefficiency - of trying to recreate it from
emails.

So I'd rather encourage people to have git branches that they expose,
if CI is the main use case.

For an example of how to do this right, look at what Al does. Recent
patch series posted at

   https://lore.kernel.org/all/20250906090738.GA31600@ZenIV/

is a good example, and notice Al saying:

  Branches are in
  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.path and
  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.f_path resp.;
  individual patches in followups.

in the cover letter.

In other words: if the series was exported from a git tree and you
have a base to use, why would it *EVER* be sane to then use 'b4
shazam' to get it?

So I think what 'b4 shazam' _should_ be looking at is when Greg says
"I like this a lot".

I think it should aim for supporting maintainers that apply patch
series as part of their workflow, not at CI tools that have the WRONG
workflow.

And yes, maybe fixing the CI tool workflow then involves having people
who post patch series post the git branch too.

I often find the git branches nicer for walking through some patch
series anyway. But it goes both ways: for short series, since I'm in
the MUA, just walking through five or six patches and replying to them
is simpler, for longer series that do more involved things, I find
doing a "git fetch" and then using git tooling to look at particular
_parts_ of the series can be a lot more powerful.

In fact, for long series that get reposted, just to not mess up my
mailbox I would generally prefer to just see the git branch over some
50-email patch bomb.

Maybe *that* would be a good addition for 'b4', where you can reply to
just the cover letter and say "Ack for this series" or explicitly
reply to particular patches - that might not even have been posted -
by mentioning their commit IDs.

That's my workflow much of the time, see for example

   https://lore.kernel.org/all/CAHk-=wgZEkSNKFe_=W=OcoMTQiwq8j017mh+TUR4AV9GiMPQLA@mail.gmail.com/

where I basically went through the series, and then replied to
individual patches.

I do like the "reply to individual patches" - even when I might
actually have looked at them in git - just because then I can quote
the part I reacted to. So I do think posting the patches makes sense
as long as it's not some excessive patch-bomb, but at the same time I
do know that a lot of patch series end up being of the type where
possibly dozens of people get cc'd, but only on the one or two patches
that are relevant to them.

And then the git workflow *really* shines, because it gets you that
context (and lots of people object to getting tens or hundreds of
patches in email when only one or two are relevant to them).

              Linus