B4 doesn’t have a separate configuration file but will use
git-config to retrieve a set of b4-specific settings. This means
that you can have three levels of b4 configuration:
Since the purpose of b4 is to work with git repositories, this allows the usual fall-through configuration that can be overridden by more local settings on the repository level.
This feature is new in v0.10.
A project may ship their own b4 config with some defaults, placed in the
toplevel of the git tree. If you’re not sure where a configuration
option is coming from, check if there is a
.b4-config file in the
repository you’re currently using.
All settings are under the
b4 section. E.g to set a
option, you can just edit your
and add the following section:
[b4] midmask = https://some.host/%s
These options control many of the core features of b4.
When retrieving threads by message-id, b4 will use
midmaskto figure out from which server they should be retrieved.
When automatically generating
Link:trailers, b4 will use this setting to derive the destination URL. If you want a shorter option, you can also use
https://msgid.link/%s, which is an alias for lore.kernel.org.
If the public-inbox server provides a global searchable index (usually in
/all/, this setting can be used to query and retrieve matching discussion threads based on specific search terms – for example, to retrieve trailer updates using a series
Messages are frequently sent to multiple distribution lists, and some servers may apply content munging to modify the headers or the message content. B4 will deduplicate the results and this configuration option defines the priority given to the
List-Idheader. It is a simple comma-separated string with shell-style globbing.
The “mbox” file format is actually several incompatible formats (“mboxo” vs “mboxrd”, for example). If you want to avoid dealing with this problem, you can choose to always save retrieved messages as a Maildir instead.
This lets you control the order of trailers that get added to your own custody section of the commit message. By default, b4 will apply these trailers in the order they were received (because this is mostly consumed by tooling and the order does not matter). However, if you wanted to list things in a specific order, you could try something like:
trailer-order = link*,fixes*,acked*,reviewed*,tested*,*
The “chain of custody” is an important concept in patch-based code review process, with each “Signed-off-by” trailer indicating where the custody section of previous reviewer ends and the new one starts. Your own custody section is anything between the previous-to-last “Signed-off-by” trailer (if any) and the bottom of the trailer section. E.g.:
Fixes: abcde (Commit info) Suggested-by: Alex Reporter <email@example.com> Signed-off-by: Betty Developer <firstname.lastname@example.org> Acked-by: Chandra Acker <email@example.com> Reviewed-by: Debby Reviewer <firstname.lastname@example.org> Signed-off-by: Ezri Submaintainer <email@example.com> Link: https://firstname.lastname@example.org Tested-by: Finn Tester <email@example.com> Signed-off-by: Your Name <firstname.lastname@example.org>
Your custody section is beneath “Ezri Submaintainer”, so the only trailers considered for reordering are “Link” and “Tested-by” (your own Signed-off-by trailer is always at the bottom of your own custody section).
Note: versions prior to v0.10 did not properly respect the chain of custody.
A comma-separated list of addresses that should never be considered for follow-up trailers. This is useful when dealing with reports generated by automated bots that may insert trailer suggestions, such as the “kernel test robot.” E.g.:
[b4] trailers-ignore-from = email@example.com, firstname.lastname@example.org
B4 will cache retrieved threads by default, and this allows tweaking the time (in minutes) before cache is invalidated. Many commands also allow the
--no-cacheflag to force remote lookups.
These settings control how
b4 shazam applies patches to your tree.
Additional flags to pass to
git amwhen applying patches.
Additional flags to pass to
git mergewhen performing a merge with
b4 shazam -M
Path to a template to use when creating a merge commit. See
shazam-merge-template.examplefor some info on how to tweak one.
B4 supports domain-level and end-to-end attestation of patches using the patatt library. There are four different operation modes:
off: do not bother checking attestation at all
check: print green checkmarks when attestation is passing, but nothing if attestation is failing (DEPRECATED, use
softfail: print green checkmarks when attestation is passing and red x-marks when it is failing
hardfail: exit with an error when any attestation checks fail
When reporting attestation results, b4 can output fancy unicode checkmarks, or plain old ascii ones:
fancy: uses ✓/✗ checkmarks and colours
plain: uses x/v checkmarks and no colours
Controls whether to perform DKIM attestation checks.
This setting controls how long in the past attestation signatures can be made before we stop considering them valid. This helps avoid an attack where someone resends valid old patches that contain a known vulnerability.
This allows setting
GNUPGHOMEbefore running PGP attestation checks using GnuPG.
If you don’t want to use the default
gpgcommand, you can specify a path to a different binary. B4 will also use git’s
gpg.programsetting, if found.
patattfor details on how to configure keyring lookups. For example, you can clone the kernel.org pgpkeys.git repository and use it for attestation without needing to import any keys into your GnuPG keyring:
git clone https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Then set the following in your
[b4] keyringsrc = ~/path/to/pgpkeys/.keyring
Thank-you (ty) settings
These settings control the behaviour of
b4 ty command.
These settings take a full path to the template to use when generating thank-you messages for contributors. See example templates provided with the project.
Used when creating summaries for
b4 ty, and can be set to a value like:
thanks-commit-url-mask = https://git.kernel.org/username/c/%.12s
If not set, b4 will just specify the commit hashes.
See this page for more info on convenient git.kernel.org shorterners: https://korg.docs.kernel.org/git-url-shorteners.html
A comma-separated list of shell-style globbing patterns with addresses that should always be excluded from the recipient list.
Sendemail identity to use when sending mail directly from b4 (applies to
b4 ty). See
man git-send-emailfor info about sendemail identities.
When set to
yes, will instruct
b4 tyto send email directly instead of generating .thanks files.
Patchwork integration settings
If your project uses a patchwork server, these settings allow you to integrate your b4 workflow with patchwork.
The URL of your patchwork server. Note, that this should point at the toplevel of your patchwork installation and NOT at the project patch listing. E.g.:
You should be able to obtain an API key from your patchwork user profile. This API key will be used to perform actions on your behalf.
This should contain the name of your patchwork project, as seen in the URL subpath to it (e.g.
When patchwork integration is enabled, every time you run
b4 shazam, b4 will mark those patches as with this state. E.g.:
After you run
b4 tyto thank the contributor, b4 will move the matching patches into this state. E.g.:
If you run
b4 ty -dto delete the tracking information for a patch series, it will also be set on the patchwork server with this state. E.g.:
The web submission endpoint to use (see Authenticating with the web submission endpoint).
Address or comma-separated addresses to always add to the To: header (see Prepare the list of recipients).
Address or comma-separated addresses to always add to the Cc: header (see Prepare the list of recipients).
Do not sign patches with patatt before sending them (unless using the web submission endpoint where signing is required).
Command to use to generate the list of To: recipients. Has no effect if the specified script is not found in the repository.
scripts/get_maintainer.pl --nogit --nogit-fallback --nogit-chief-penguins --norolestats --nol
Command to use to generate the list of Cc: recipients. Has no effect if the specified script is not found in the repository.
scripts/get_maintainer.pl --nogit --nogit-fallback --nogit-chief-penguins --norolestats --nom
Alternative cover letter storage strategy to use (see Cover letter strategies).
Path to the template to use for the cover letter.
Deliberately undocumented because the feature is incomplete and poorly tested.