Re: [PATCH v4 00/10] net: support thread-specific pidfds for send and connect

[Konstantin Ryabitsev <konstantin@linuxfoundation.org>]

On Fri, Oct 16, 2026 at 08:57:32AM -0700, Jakub Kicinski wrote:
> Konstantin, could you consider adding a b4 option which would
> make it apply the patches on the most recent Linus release tag
> and then merge them into current branch as normal?
> Simpler version is to let the user name the application base.
> This lets other trees trivially create a branch later if they
> want to.

This was a fairly frequent request, so I made this change now:

    b4 shazam -M <msgid>

applies the series on the nearest annotated tag in the history of your current
branch (e.g. v7.3-rc6), and then merges it into your branch with the cover
letter as the merge message, just like a pull request. If the series doesn't
apply cleanly on that tag, or there is no annotated tag, b4 falls back to
applying on HEAD and tells you why.

As previously, use -H instead of -M if you just want the result in FETCH_HEAD
so you can look at it first.

If you don't want to upgrade to current master, you can already use
--merge-base to achieve the same effect:

    b4 shazam -M --merge-base v7.3-rc6 <msgid>

It takes any commit, branch, or tag. The most recent master also takes a few
new markers: _tag (the nearest annotated tag, with no fallback to HEAD),
_specified (the series' own base-commit, which is what -M used before), and
_guess (guess from the blob hashes in the patches).

The breaking change here is that b4 no longer uses the series' base-commit by
default -- it was always envisioned as more of a hint for the CI systems. As
far as I'm aware, almost every real maintainer wants to apply to HEAD or, at
least, to the most recent tag as the base.

One potential pitfall: b4 can't know if "the nearest ancestor annotated tag"
is actually useful or meaningful, so if your own annotated pull request tags
(e.g. net-7.3-rc7) are in the history of your branch, one of those could end
up being the nearest tag. b4 always prints which tag it picked, so if you see
that, just pass --merge-base with the release tag you wanted.

The same logic now is in the "b4 review" TUI when taking a series with the
merge method: the dialog shows which base it's going to use and lets you
change it before anything is applied. I know Mark has been asking for this
(cc'ing him for review).

Please let me know if this works for your workflow, or if you run into
problems, or if I completely misunderstood the request. :)

-K