Release notes

v0.16

b4 bugs — bug tracking with git-bug (technology preview)

The new b4 bugs command integrates with git-bug to let you track bug reports alongside your git repository. Bugs are stored as git objects inside the repo, so they travel with the code and can be shared via git push/git pull without any external service.

A full-featured TUI (b4 bugs tui) lets you browse, triage, and update bugs; a lightweight CLI covers scripting and non-interactive use. Key capabilities:

• Import from lore — enter a Message-ID and b4 fetches the full thread, uses the oldest message as the bug report, and adds follow-ups as comments. Importing the same thread twice is detected and prevented.

• Lifecycle states — triage bugs through new → confirmed → fixed (and needinfo, wontfix, duplicate, worksforme). State is tracked via internal lifecycle: labels.

• Comment tombstoning — remove personal data from a comment while preserving the Message-ID, so thread refresh does not re-import it.

• Label editing — add and remove arbitrary labels from the TUI or CLI.

b4 bugs is a technology preview (alpha): commands, keybindings, and formats may change between releases. See bugs: bug tracking with git-bug (alpha) for the full reference.

b4 review — tracking and review improvements

Several notable improvements to the b4 review workflow shipped this cycle, building on the v0.15 foundation.

Manual revision linking

When automatic revision discovery fails — for example, a submitter sent v2 to a different mailing list or without proper in-reply-to threading — you can now link a revision by hand. Open the action menu (a) on a new or actively reviewed series and select Link a revision (l). B4 prompts for a message-id or lore URL, fetches the posting in the background, and shows a confirmation preview before recording the link. See Linking a revision manually for details.

Reworked revision-upgrade flow

“A newer revision exists” is now tracked as its own attribute instead of being folded into the series status, fixing a cluster of upgrade-flow problems reported by Mark Brown. Updating a series only records discovered revisions — the old implicit promotion of waiting series back to reviewing is gone, so status changes only happen through explicit actions. When a newer revision is known, the series row gets an ↑ flag, a waiting series surfaces back into the active group, and a new up: limit token filters the list to upgradable series. The Upgrade action is now offered from any state that can hold a newer revision (including waiting and partial — previously both required detouring through reviewing first), and lands the upgraded series back in reviewing.

Thank and archive in one motion

The Take dialog grew a thank and archive on delivery checkbox (default off; set b4.review-thank-and-archive to pre-check it). When enabled, a take that fully accepts the series chains straight into the thank-you preview, and a successful delivery of the thank-you — immediately for a direct send, or when a queued message goes out via the queue delivery or b4 review cron — also archives the series. The archive is skipped when a newer revision has appeared in the meantime or the series status changed while the message was queued, so the automation never sweeps away something you are still working on. To go with this, the Upgrade action is now also offered on accepted and thanked series with a known newer revision. See thank and archive in one motion.

Send is now Ctrl-y

Sending mail from a preview screen — review emails, thank-you notes, follow-up replies, and b4 bugs replies — is now confirmed with Ctrl-y, matching the confirmation chord used by every other important dialog. The old S binding still works as an unlisted legacy alias, so existing muscle memory is not broken.

Partial-series state

When you cherry-pick only a subset of a series’ patches, b4 now sets the series status to partial (◐) rather than accepted. The review branch stays alive, new revisions are ingested as normal, and a Thank action is available so you can acknowledge the patches already applied without closing the review. When subsequent takes complete coverage, b4 automatically promotes the status to accepted.

Unchanged-patch marker on revision upgrade

After upgrading to a new revision, patches whose content did not change from the previous revision are automatically marked with the ≡ (unchanged) indicator in the patch list. This lets you focus your review on what actually changed between revisions.

Auto-detection of prior reviewer trailers

If you already replied to one or more patches in a series with a Reviewed-by or Acked-by trailer before tracking it in b4 review, those patches are now detected from the thread and marked ✓ Done automatically. Any subsequent action (a new comment, a Nacked-by, or a manual x skip) takes precedence.

Network operation cancellation

Long-running network operations — fetching threads from lore, running attestation checks, tracking a new series — can now be interrupted at any time by pressing Escape or q. B4 exits cleanly from any cancellation point without leaving dangling state.

Quitting takes a capital Q

Bare q shares the keyboard with the heavily used navigation keys, making it too easy to quit a TUI accidentally. All b4 TUI apps (tracking list, review interface, Patchwork browser, and b4 bugs) now quit on capital Q; bare q shows a reminder notification instead. Modal dialogs and sub-views still close with q as before. In the tracking list, the thank-you queue moved from Q to T to make room.

Patchwork backlog gate

Opening the Patchwork browser against a project with a large number of outstanding patches no longer hangs. B4 now probes the outstanding patch count first; if it exceeds 1000, the fetch is automatically restricted to the last 30 days. A self-dismissing notice informs you when the window is active, and the title bar shows “· last 30 days” so the absence of older series does not look like data loss.

Takes run in the target branch’s worktree

Applying a series no longer checks the target branch out in your current worktree. Patches are applied in whichever worktree has the target branch checked out — or in a throwaway worktree when it is not checked out anywhere — so the checkout you are driving the TUI from is never touched. Merge conflicts during a take are now resolved in place in a conflict shell (previously the take was aborted and discarded), an abandoned resolution can no longer leave a real checkout stuck mid-merge, and a take refuses to start on a worktree that already has an operation in progress. See Conflict resolution.

Cover-letter-aware take defaults

The Take dialog now defaults to the linear method when the submitter provided no cover letter — a merge commit’s message is built from the cover letter, so there is nothing to build it from — and shows a note so the missing cover is visible before you take. Set b4.review-default-take-method to override the heuristic.

Configurable apply-base pre-fill

The base selection dialog shown when starting a review or upgrading to a newer revision can now be pre-filled from configuration. Set b4.review-apply-base to anything that resolves to a commit (HEAD, a branch, a tag, or a SHA) and it takes priority over the base named by the series and over b4’s own guess — which is still shown in the dialog hint, so no information is lost. The dialog stays editable and the value is validated on confirm; an unresolvable setting falls back to automatic detection with a warning in the hint.

More reliable series matching and revision discovery

Series whose patches carry plain (non-git) diffs no longer collapse onto one another when tracked: the series fingerprint hashes the diff content when git patch-id is unavailable, and a message-id match now always takes precedence over a fingerprint match. Discovered revisions are also identified by their cover letter rather than their first patch, so revision listings show the real series subject.

Non-interactive maintenance with b4 review cron

Everything the TUI does periodically can now run from a scheduler or a git-push wrapper. b4 review cron wakes expired snoozes, rescans review branches, updates all tracked series, and delivers queued thank-you messages whose commits have been published. With no flags it runs the full sweep; --update and --deliver-queue select one task group, and --dry-run reports what queue delivery would do without sending anything. Run from within an enrolled repository it works on that project; from anywhere else it sweeps every known project, with -i (repeatable) limiting the run to the named ones. The shared code paths are guarded by per-repository locks, so a cron run overlapping an interactive session skips the busy task instead of double-sending thanks or racing the tracking database. Output is scheduler-friendly: the progress narration of the underlying interactive code paths is suppressed, so a cron mail only arrives when something actually happened. See Non-interactive maintenance (b4 review cron).

Queued thanks wait for the actual push

Queued thank-you messages used to be held back by an HTTP check of the commit URL, which hosts with shared object storage (git.kernel.org, github fork networks) answer positively as soon as the commit exists in any sibling repository — so a push to a CI tree could release the thanks before the public tree was updated. Delivery now verifies, via git ls-remote, that the commit is reachable from the branch named in the thank-you message on the repository the “Applied to” line refers to: the per-remote b4-check-repo setting, b4.thanks-check-repo, or by default the URL of the remote the target branch tracks. Reported by Mark Brown.

Custom reply templates

Outgoing review replies — both per-patch replies and the cover-letter reply — can now be wrapped in a template of your own, for example to add a standard greeting or a review-process boilerplate. Point b4.review-reply-template at a template file containing the ${reply} placeholder; substitution follows the same rules as the b4 ty thank-you templates, and a commented starting point ships with b4 as review-reply-template.example.

Your own replies no longer show up as unread

After sending a reply, the reply itself would arrive back from the mailing list a few moments later and light up the series’ unread badge. Replies sent through b4 are now marked as read at send time, and any fetched message whose From: exactly matches your configured identity (sendemail.from, falling back to user.email) is marked as read during update checks. Mail you send from any other address is deliberately left untouched, so a missed match can only ever leave a message unread — never silently hide one.

Other review fixes

• Unread-message badges keep working after a series is applied: message counts are now refreshed for accepted, thanked, and snoozed series too.

• Pressing d on a patch that carries a Reviewed-by/Acked-by trailer now really takes it out of the done state, via an explicit draft state that also guards against sending unfinished comments.

• Inline comments on cover letters and commit messages are re-anchored by content, so an editor that re-wraps the quoted text no longer makes comments drift away from the lines they respond to.

b4 trailers — interactive review and fuzzy matching

Two new flags make trailer recovery more controlled.

b4 trailers -u -i

Opens your editor with the list of trailers about to be applied, grouped per commit and annotated with their source message. Change a leading + to x to reject a trailer; the rejection is persisted in .git/b4-trailers-ignore.json and honoured on future runs, even after a reroll.

b4 trailers -u --fuzzy

When a commit’s patch-id no longer matches what was posted (after a rebase or amend), additionally try to match by Link: message-id and then by subject instead of skipping it. Best combined with -i so you can review each recovered trailer before it is applied.

See trailers: retrieving code-review trailers for details.

b4 ty — interactive review before sending

b4 ty -i opens your editor with the list of thank-you messages the auto-thankanator detected, each pre-marked to send. Change a + to x to skip an individual entry — it stays pending for the next run. Editing, adding, removing, or reordering the entry lines aborts the run without sending anything.

b4 review track --rethread

Submitters who send patches without threading (each patch as a separate, unrelated message) can now be accommodated with --rethread. Pass any single patch from the series; b4 auto-discovers the rest by searching lore for other patches from the same author sent within a 1-hour window, matching by [PATCH n/m] counters and version. You can also supply all message-ids explicitly or read them from stdin.

If the submitter also posted a correctly threaded re-send of the same version, b4 prefers that copy instead of stitching. --rethread also records an unthreaded new version of an already-tracked series as a new revision rather than a duplicate.

b4 shazam — conflict-resolution overhaul

b4 shazam --resolve now resolves conflicts inline: on a git am conflict, b4 parks the in-progress apply in a throwaway worktree and drops you into a sub-shell there. Finish with git am --continue (or back out with git am --abort), leave the shell, and b4 completes the operation. The previous two-phase flow — and with it the --continue/--abort subcommands and the persisted state file — is gone.

The conflicted series is applied entirely through native git am, which fixes a serious bug where a patch whose three-way fallback could not run was silently dropped from the merge. Conflicts in files below the repository root are also handled now. See Dealing with patches that don’t apply cleanly for the new workflow.

Separately, “naked” cover letters — ones lacking both a [PATCH 0/N] subject prefix and a diffstat — are now recognized when they are the same-author root of the thread, so b4 shazam -M uses the real cover letter for the merge commit message instead of reporting that no cover letter was provided.

Vim and Emacs editor plugins

The misc/ directory now includes syntax highlighting and editing helpers for both Vim and Emacs. Both plugins provide:

• Diff-aware syntax highlighting — quoted additions in green, removals in red, hunk headers in cyan, external | comments visually bracketed, your own comments in the default foreground, with spell checking limited to your comment lines.

• Hunk trimming — delete a hunk or all uncommented hunks above the cursor, leaving a [ ... NN lines skipped ... ] breadcrumb so recipients can see that context was intentionally omitted. An opt-in auto_marker mode extends this to ordinary delete commands.

• Adopt-comment — strip the | prefix from an external reviewer comment (from a follow-up or AI agent) to claim it as your own, ready to edit and send.

See Editor syntax highlighting in the reference for setup instructions.

New configuration options

b4.custom-msgid-cmd

An optional command whose stdout is used as the Message-Id for review replies, follow-up replies, and b4 ty thank-you notes. Useful for maintainers who rely on a custom message-id scheme and whose SMTP path does not run a sendemail-validate hook. Falls back to b4’s built-in id on unset, failure, or empty output.

b4.send-me-too

Set to no to suppress including your own address in the Cc when sending patches with b4 send. Defaults to yes (include yourself).

In-tree ``.b4-config`` changes

Because a .b4-config file travels with the repository and may come from a source you don’t fully trust, b4 only honors an allowlist of settings from it; the trust model is now documented at the top of Configuration options. Two changes to the allowlist this cycle: b4.prep-pre-flight-checks is now accepted, so a project can share which pre-flight checks it disables, while the review check commands (review-*-check-cmd) are no longer read from .b4-config — b4 review applies the series under review into your working tree, so honoring them would let a malicious series plant a command that a later review session runs.

Native history rewriting (replaces git-filter-repo)

b4 no longer depends on git-filter-repo for the two operations that rewrite commit history on a prep branch (cover-letter updates and trailer application via b4 trailers -u). The rewrite is now implemented natively using pygit2, which b4 already pulls in through the ezgb dependency. Existing safety backups continue to live at refs/original/<branch>.

The migration also fixes a long-standing issue where git notes attached to rewritten commits were silently orphaned on the old commit OIDs (upstream git-filter-repo issue #22). b4 now migrates entries under any refs/notes/* ref onto the new commit OIDs after a rewrite, preserving note message bytes verbatim.

GPG signatures on rewritten commits continue to be stripped, as they were previously with git-filter-repo. Re-sign from refs/original/<branch> if needed — for example:

git rebase --exec 'git commit --amend -S --no-edit' \
    refs/original/<branch>

Committer integrity and b4 prep --claim

History rewrites are now honest about the committer: rewritten commits are always stamped with your current git identity instead of preserving the original committer, and b4 refuses outright to rewrite any commit that was committed by someone else. Operations that would do so — for example b4 trailers -u on a series enrolled from another maintainer’s tree — stop with a message pointing at b4 prep --claim, the deliberate, opt-in way to take ownership of a branch: it re-stamps the cover letter and every patch under your current identity, leaving patch authorship untouched.

b4 prep also now recognizes a prep branch whose cover commit was created under a different user.email (a common effect of changing git identities) and suggests --claim, instead of insisting the branch is not prep-managed.

Compatibility with distro-shipped dependencies

b4 is now tested against the dependency versions distributions actually ship, and several findings from that are fixed: the pygit2 floor is lowered to 1.14 so b4 installs entirely from packages on EL10-family distributions, the test suite runs (and self-skips TUI tests) on installs without the [tui] extra, and two review-TUI crashes on older Textual releases (as shipped by Debian stable and Fedora) are resolved.

v0.15

b4 review — TUI-based patch review workflow (technology preview)

This release introduces b4 review, a new terminal-based workflow for maintainers who receive, review, and accept patches from mailing lists. It ships as a technology preview (alpha): the commands, keybindings, configuration options, and on-disk formats may change in incompatible ways between releases. Bug reports and feedback are welcome at tools@kernel.org.

Note

The TUI requires the optional tui dependency group. Install with pipx install b4[tui] or uv tool install b4[tui].

The workflow is built around a lightweight SQLite tracking database and per-series review branches. It comprises three cooperating TUI apps:

Tracking TUI (b4 review tui)

Browse and manage tracked series with status indicators, take (apply) series using merge, linear, or cherry-pick strategies, compare revisions with range-diff, send thank-you messages, and archive completed series. The app groups series by lifecycle state (active, new, waiting, gone) and sorts by most-recent activity.

Review TUI (b4 review <branch>)

Split-pane interface with a patch list and scrollable diff viewer. Add inline comments and code-review trailers, preview outgoing emails, invoke an external AI agent for automated review assistance, and send review replies — all without leaving the terminal.

Patchwork TUI (b4 review pw)

Browse outstanding series from a Patchwork server, set state and archived flags, and track series into the local database for review.

Highlights:

• Series tracking and lifecycle management — track series from the CLI (b4 review track <msgid>), from your mail client, or from Patchwork. Series progress through new → reviewing → replied → accepted → thanked states.

• Revision discovery and upgrades — b4 automatically discovers older and newer revisions of a tracked series using change-id and in-reply-to chains. Upgrading to a newer revision preserves your review state and prior context.

• Inline commenting — press r in the review view to open $EDITOR with the full diff quoted. Write your comments below the relevant lines and b4 will format them as proper email replies. The diff view shows community follow-up comments from the mailing list alongside your own.

• AI agent integration — optionally invoke an external AI agent (Claude Code, Gemini CLI, OpenAI Codex CLI, or GitHub Copilot CLI) to produce a first-pass review. Agent findings remain private to you; you decide what, if anything, to include in your reply.

• Per-patch state machine — mark individual patches as done (✓), skip (✕), or draft (✎) to track your progress through large series. B4 automatically excludes skipped patches from cherry-pick selection and outgoing emails.

• Three take strategies — merge (creates a merge commit from the cover letter), linear (git am), or cherry-pick (select individual patches). B4 adds per-commit Signed-off-by and Link trailers on request.

• Snooze — defer a series until a specific date, duration, or git tag. B4 skips snoozed series during bulk updates and automatically wakes them when the snooze expires.

• Cross-machine synchronisation — push b4/review/* branches to a private remote and rescan on another machine to rebuild the tracking database from branch metadata.

• Mutt-style thread viewer — press e to browse the full email thread with tree art, attestation status display, and reply support. B4 tracks per-message flags (seen, flagged, answered) across sessions.

• Worktree support — enrolled repositories work correctly from worktrees; a configurable review-target-branch sets the default branch for take operations.

• Patchwork state synchronisation — when you have write access to a Patchwork instance, b4 automatically updates the remote series state as you progress through the review lifecycle.

• Prior review context — when upgrading to a new revision, b4 carries forward your previous review comments and notes so you can see what you said last time.

• Quick-reply — reply to follow-up messages directly from the review TUI or thread viewer without switching to your email client.

See Getting started with b4 review for a walkthrough with screencasts, and review: TUI-based patch review workflow (alpha) for the full reference.

b4 dig — trace applied commits back to mailing list submissions

The new b4 dig command searches for the original mailing list submission of a commit that has already been applied to a git tree. It matches by patch-id, author, and subject to locate the original thread on lore.kernel.org.

b4 dig -c <commitish>
b4 dig -c <commitish> --all-series
b4 dig -c <commitish> --who
b4 dig -c <commitish> --save-mbox /tmp/thread.mbx

The --all-series flag shows all revisions of the series containing the commit. The --who flag shows who was originally included on the thread (To/Cc recipients), and --save-mbox saves the matched thread to a local mbox file. See dig: finding commit origins for details.

b4 shazam — three-way merge and conflict resolution

b4 shazam -H now performs a three-way merge when applying patches, which significantly improves the success rate for series that do not apply cleanly with a simple git am. When conflicts do occur, the new --resolve flag drops you into an interactive conflict resolution session instead of aborting:

b4 shazam -H --resolve <msgid>

b4 prep — pre/post history-rewrite hooks

Two new configuration keys let you run commands before and after b4 rewrites history on a prep branch (for example, when updating the cover letter or applying trailers):

b4.prep-pre-rewrite-hook

Command to run before the rewrite. A non-zero exit aborts the operation, which is useful for tools like StGit that need to commit their internal state first.

b4.prep-post-rewrite-hook

Command to run after a successful rewrite. A non-zero exit logs a warning but does not undo the rewrite.

Example for StGit users:

[b4]
    prep-pre-rewrite-hook = stg commit --all
    prep-post-rewrite-hook = stg repair

Other notable changes

New features and enhancements:

• XOAUTH2 and bearer-token SMTP authentication — b4 can now use XOAUTH2 or bearer tokens to authenticate to SMTP servers, for environments that do not support basic authentication.

• Presubject support — set b4.send-presubject or use --set-presubject to add a prefix before the standard [PATCH] subject tag.

• Send-email aliases — b4 now reads sendemail.aliasesfile and sendemail.aliasfiletype to expand aliases in To/Cc fields, the same way git send-email does.

• Codespell integration — b4 prep --check now runs codespell as a spellcheck pass when the codespell tool is installed.

• Shallow same-thread support — b4.send-same-thread = shallow sends follow-up versions as a reply to the cover letter of the previous version rather than the entire thread.

• Force cover letter for single-patch series — use b4 send --force-cover-letter to generate a separate cover letter even when the series has only one patch.

• Default Link domain — the default linkmask now uses patch.msgid.link instead of lore.kernel.org.

• Full-index binary diffs — b4 now creates patches with --full-index --binary for more reliable application.

• Clean multiple prep branches — b4 prep --cleanup now accepts multiple branch names at once.

• Thank-you self-copy — b4 ty --me-too sends a copy of the thank-you message to yourself.

• Range-diff arguments — b4 prep --compare-to and b4 diff now accept --range-diff-opts to pass additional flags to git range-diff.

• Trailer provenance — b4 trailers now shows the message-id and source of each trailer it discovers.

• Pre-flight check improvements — check output now includes the exit code and stderr from check commands for easier debugging.

Thanks

Thanks to the following people for reporting bugs, suggesting features, reviewing patches, testing, and contributing code:

• Alexey Minnekhanov

• Andrew Cooper

• Andy Shevchenko

• Christian Heusel

• Conor Dooley

• Dave Marquardt

• Geert Uytterhoeven

• Jonathan Corbet

• Junio C Hamano

• Juri Lelli

• Kevin Hilman

• Krzysztof Kozlowski

• Lee Jones

• Linus Torvalds

• Louis Chauvet

• Luca Ceresoli

• Manos Pitsidianakis

• Marc Kleine-Budde

• Mark Brown

• Matthieu Baerts

• Maxime Ripard

• Michael S. Tsirkin

• Miguel Ojeda

• Nathan Chancellor

• Panagiotis Vasilopoulos

• Ricardo Ribalda

• Rob Herring

• Tamir Duberstein

• Toke Høiland-Jørgensen