B4(1)

📦 version 0.15.2, in arch rolling, ubuntu stonking

🦋 B4(1) 🦋

okay so this is B4(1), out of the General Commands Manual, and it's genuinely one of the most useful little helpers if you live in a patch-based workflow. Bestie, let me walk you through it. 💖

🎀 NAME 🎀

B4 — work with code submissions in a public-inbox archive. that's the whole vibe, periodt. ✨

🌸 SYNOPSIS 🌸

b4 {mbox,am,shazam,pr,diff,ty,kr,dig,review,prep,send,trailers} [options]

🦋 DESCRIPTION 🦋

So this is a helper utility for working with patches and pull requests that live in a public-inbox archive like lore.kernel.org. It was written to make it simpler to participate in patch-based workflows — you know, the kind the Linux kernel development uses. 🔥

The name b4 was chosen for ease of typing and because B-4 was the precursor to Lore and Data in the Star Trek universe. iconic origin story tbh. 🖖

Full documentation is available over at https://b4.docs.kernel.org/. 📚

👑 SUBCOMMANDS 👑

Here's the cast of characters, split by who they're for. 🫶

Maintainer-oriented:

  • mbox — download a thread as an mbox file
  • am — create an mbox file that is ready to git-am
  • shazam — apply patch series to git repositories
  • pr — work with pull requests
  • ty — create templated replies for processed patches and pull requests
  • diff — show range-diff style diffs between patch versions
  • dig — find the mailing list submission for a given commit
  • review — TUI-based patch review workflow (alpha)
  • kr — (STUB) operate on patatt-compatible keyrings

Contributor-oriented:

  • prep — prepare your series for submission
  • trailers — retrieve and apply code-review trailers
  • send — send your series for review on distribution lists

For the full options and what they actually do, please see b4 --help and b4 subcommand --help. no cap. 💅

📬 b4 mbox 📬

This command lets you retrieve entire threads from a remote public-inbox instance. You can open the resulting mbox file with most mail clients so you can reply to conversations or review patch submissions. 🍓

You can hand over the message either as a msgid, as a full URL to a public-inbox archive, or you can just pipe it on stdin. easy peasy.

For options and their descriptions, see b4 mbox --help.

✨ Examples ✨

  • b4 mbox [msgid] — download a thread from the default public-inbox server and save it in the current directory as a .mbox file.
  • b4 mbox -m ~/Mail [msgid] — download a thread from your ~/Mail folder and save it in the current directory as a .mbox file.
  • b4 mbox -fo ~/Mail [public-inbox-url] — download the thread from this public-inbox server, and add it to your existing mailbox, filtering out any dupes already in your mailbox folder.

🎯 b4 am 🎯

This one retrieves threads from a public-inbox instance and gets them ready to apply to a git repository using the git am command. It automatically does all of this for you:

  • picks the latest submitted version of the series (it can check for newer threads using -c as well)
  • checks DKIM signatures and patatt attestation on all patches and code review messages
  • collates all submitted code-review trailers (Reviewed-by, Acked-by, etc) and puts them into the commit message
  • adds your own Signed-off-by trailer (with -s)
  • rerolls series from partial updates (e.g. someone submits a v2 of a single patch instead of rerolling the entire series)
  • guesses where in the tree history the patches belong, if the exact commit-base is not specified (with -g)
  • prepares the tree for a 3-way merge (with -3)
  • cherry-picks a subset of patches from a large series (with -P)
Note: unless you intend to do some preparatory work on the series before applying it to the git repository (e.g. a 3-way merge), you should consider using b4 shazam to apply the retrieved series. 👀

For options and their descriptions, see b4 am --help.

✨ Examples ✨

  • b4 am -sl [msgid] — download a thread from the default public-inbox server, apply any follow-up trailers, add your own Signed-Off-By trailer plus a Link: trailer indicating the origin of the patch, then save the resulting .mbox file in the current directory ready to be applied by git am.
  • b4 am -sl -P 1-3 [msgid] — same as the previous example, but pick only patches 1,2,3 from the entire series.
  • b4 am -3 [msgid] — download the series and prepare the local git tree for a 3-way merge by ensuring that all index blobs exist.
  • b4 am --check [msgid] — download the series and show if it passes the checks. You can specify the command using the b4.am-perpatch-check-cmd configuration option. For the Linux kernel, the default will be the most common checkpatch.pl set of options.

⚡ b4 shazam ⚡

This is very similar to b4 am, but it also applies patches directly to the current git tree using git am. Alternatively, when you use it with -H, it can fetch the patch series into FETCH_HEAD as if it were a pull request, ready for you to review and merge. B4 uses the cover letter as a template for the merge commit. 💖

If you want it to automatically invoke git-merge, you can use -M instead of -H. B4 automatically opens up the editor so you can edit the merge commit message. ✍️

When you're using -H, you can pass --resolve to interactively resolve any merge conflicts using a three-way merge. 😤

Note: the -M and -H options work best for series that have the base-commit info matching an object in your local tree.

For options and their descriptions, see b4 shazam --help.

✨ Examples ✨

  • b4 shazam -sl -M [msgid] — download a thread from the default public-inbox server, apply any follow-up trailers, add your own Signed-Off-By trailer plus a Link: trailer with the origin of the patch, then merge this commit to the current git repository using the cover letter as the merge commit template.
  • b4 shazam -sl -M --merge-base v6.4-rc4 [msgid] — same as the previous example, but forces the merge-base to be the commit-ish object provided instead of the one listed in the patch series itself.

🫶 b4 pr 🫶

This command is for working with pull requests submitted using git-request-pull. Compared to just using git directly, it gives you these benefits:

  • it can check if the pull is already applied before performing a git fetch
  • it checks the signature on the tag or tip commit specified in the pull request
  • it can track applied pull requests and send replies to submitters using b4 ty

For options and their descriptions, see b4 pr --help.

✨ Examples ✨

  • b4 pr [msgid] — download the message with the pull-request and apply it to the current git tree.

💌 b4 ty 💌

If you've retrieved and applied some patches to your tree, you should be able to fire up the “auto-thankanator”, which uses patch-id and commit subject tracking to figure out which series from those you have retrieved you already applied to your tree. The process is usually pretty fast and fairly accurate. 👑

To send mails directly using -S, you should have a configured [sendemail] section somewhere in your applicable git configuration files. By default, b4 ty writes out .thanks files in the current directory that you can edit and send out using a command like mutt -f thanks.file.

For options and their descriptions, see b4 ty --help.

✨ Examples ✨

  • b4 ty -a -S — locate any retrieved series that you have applied to the current git repository and send out thanks to all members of the conversation.
  • b4 ty -a -S --dry-run — same as above, but instead of actually sending it out, show what the message is going to be first. 🙈

🔍 b4 diff 🔍

The diff subcommand lets you compare two different revisions of the same patch series using git range-diff. heads up though — in order to perform the range-diff comparison, both revisions need to cleanly apply to the current tree, which may not always be possible to achieve. 😭

For options and their descriptions, see b4 diff --help.

✨ Examples ✨

  • b4 diff [msgid-of-vN] — retrieves the thread matching the msgid specified and attempts to auto-locate the previous version of the series. If successful, shows the output of git range-diff comparing the patch differences.

🕵️ b4 dig 🕵️

Given a commit in a local git repository, this command tries to find the original mailing list submission on a public-inbox instance. It uses several strategies, in order of reliability:

  • match by stable patch-id (tries multiple diff algorithms)
  • match by author email and subject
  • match by in-body From: line (for patches sent from a different address than the commit author)

If --all is specified, b4 will also try to locate all other revisions of the same series using change-id or subject matching. 🌈

For options and their descriptions, see b4 dig --help.

✨ Examples ✨

  • b4 dig [commit] — find the mailing list submission for the given commit and print a link to it.
  • b4 dig -a [commit] — find all revisions of the series containing the given commit.
  • b4 dig -w [commit] — find the submission and show who was originally included in To/Cc.
  • b4 dig -m /tmp/thread.mbx [commit] — find the submission and save the full thread as an mbox file.

🔑 b4 kr 🔑

This subcommand lets you maintain a local keyring of contributor keys. 🗝️

Note: this part of b4 is under active development with improvements planned for the near future.

For options and their descriptions, see b4 kr --help.

✨ Examples ✨

  • b4 kr --show-keys [msgid] — retrieve the thread specified and show any cryptographic keys used to attest the patches.

🖥️ b4 review (alpha) 🖥️

Note: this subcommand is a technology preview. Commands, flags, and on-disk formats may change in incompatible ways between releases. 💀 (not in a scary way, just, like, be aware)

This command provides a TUI-based review workflow for maintainers receiving patches on mailing lists. It lets you track incoming series, review diffs with inline commenting, add code-review trailers, send review emails, and take (apply) patches. the whole glow-up. ✨

The workflow consists of three steps: enrol a repository, track one or more series, and launch the TUI to review and act on them.

For options and their descriptions, see b4 review --help and b4 review <subcommand> --help.

✨ Examples ✨

  • b4 review enroll — enrol the current repository for review tracking.
  • b4 review track <msgid> — track a series by its message-id, URL, or change-id.
  • b4 review tui — launch the review TUI.

📝 b4 prep, trailers, send 📝

These commands let you prepare and submit a patch series for review on the mailing list. Full documentation is available online at the following address:

https://b4.docs.kernel.org/en/latest/contributor/overview.html

For options, see the output of b4 prep --help, b4 trailers --help and b4 send --help.

✨ Examples ✨

  • b4 prep -n my-new-feature -f v6.4-rc4 — new series era unlocked ✨ Start a brand-new branch and fork it straight from the tag v6.4-rc4, all prepped and ready for you to stack more patches on top. It's giving fresh-start energy fr fr.
  • b4 prep --edit-cover — pop open the cover letter for the series you're working on right now and edit it 💅 Bestie, lowkey you don't need this for most single-patch submissions, so don't stress if you skip it.
  • b4 prep --auto-to-cc — no cap, this one is the goat 🐐 It hunts down every single address that needs to get a copy of your patch series submission and drops them into the cover letter for you.
  • b4 prep --check — runs the configured checks all over your series to catch any potential problems before they catch you 😭 For the Linux kernel, this runs checkpatch.pl with the recommended set of parameters.
  • b4 send -o /tmp/outdir — generates the patches b4 is about to send out and saves them into the directory you specify 📂 That way you can review the whole series before you actually send anything. Highly recommend, queen behavior.
  • b4 send --preview-to [addr1@example.com addr2@example.com] — sends a "preview" version of the series to the addresses you list, so someone can look it over before it goes upstream 👀
  • b4 trailers -u — grabs any code-review trailers that came in for your series and applies them right onto the current branch 🎀 free labor, we love to see it.

🌸 CONFIGURATION 🌸

B4 config is handled through git-config(1), so you've got options, bestie 💖 You can stash it in the toplevel $HOME/.gitconfig file, or in a per-repository .git/config file if your workflow switches up per project.

Wanna see all the config options available? The online docs live right here:

<https://b4.docs.kernel.org/en/latest/config.html>

🦋 PROXYING REQUESTS 🦋

Commands that make remote HTTP requests can be set up to go through a proxy — just set the HTTPS_PROXY environment variable 🫶 All the deets are in the docs:

<https://docs.python-requests.org/en/latest/user/advanced/#proxies>

💜 SUPPORT 💜

Need help? Please email <tools@kernel.org> with your support requests 🥺 Or if you'd rather just vibe and read, browse the list archive over at:

<https://lore.kernel.org/tools>

👑 AUTHOR 👑

mricon@kernel.org

License: GPLv2+

The Linux Foundation and contributors

and that's a wrap on the whole page, bestie!! 💅✨ version 0.15, dated 2026-03-16 — iconic, timeless, no notes 🎀🦋
📦 where this page comes from