Reviewing git patches by email without leaving Thunderbird: an old-school workflow still alive

Korben sheds light on a workflow that many young developers completely ignore: email-based patch review, Linux kernel style. A project allows you to do this without ever leaving Thunderbird - and it's more relevant than you might think.

A concrete case: contributing to the Linux kernel, git, Emacs

For a dev who has only known GitHub and GitLab, the question may seem strange: "why on earth review code by email?" Concrete answer: because the projects that structure a large part of modern computing - the Linux kernel (LKML), git itself, Emacs, U-Boot, QEMU, Postgres (partially), the majority of BSD projects - do NOT use a web forge to receive contributions. The historical workflow remains:

1. The contributor runs git format-patch to transform their branch into a series of .patch files, one per commit.
2. They send these patches to a public mailing list with git send-email.
3. Maintainers and peers respond inline in the email: they quote the lines of code from the patch with a > prefix and write their comment right below. It's code review, but in a mail client.
4. The contributor sends a v2, v3, etc. A maintainer eventually integrates the series with git am.

This flow has objective qualities that the web forge does not have: publicly indexable archives (lore.kernel.org, marc.info), participation without a GitHub account, respect for the principle "write it once, read it many times".

The tool that Korben exposes: thunderbird-patch-review

The comfort of GitHub review - syntax highlighting, line comments, Approve/Request changes - has created a generation that finds email review unreadable. Result: the barrier to contributing to the kernel is increasing, even though git send-email is an old, proven tool.

Marc Coquand wanted to bring his team into this mail-first workflow without imposing exotic tooling. He therefore developed thunderbird-patch-review, an extension for Thunderbird: when an email containing a series of patches arrives, the extension offers a button to open a comfortable review view - patch coloring, jumps to the target file, local application of the patch for testing, inline response with the correct quoting convention. The idea is not to replace GitHub, it's to be able to participate in projects that don't use it without suffering.

To find the repo and the current version, we refer to Korben's article (link in source), which points directly to Marc Coquand's repository - rather than citing a URL from memory.

How it fits together on the tooling side

To reconstruct the complete pipeline, outside of the Thunderbird extension:

• Configure your SMTP in git: git config sendemail.smtpServer <server>.
• Prepare a series with correct cover letter and threading: git format-patch -N HEAD~M with the options cover-letter (two dashes followed by cover-letter) and thread (two dashes followed by thread).
• Send the series: git send-email with the options to=list@vger.kernel.org and cc=maintainer@example.org (each prefixed with two dashes).
• On the receiving side: git am < email.mbox to apply a received series.

A fully decentralized flow, without depending on a third party. The reference documentation is git send-email(1) on git-scm.com.

Key takeaways

• The email workflow is neither dead nor marginal: it's the one used by the kernel, git, Emacs, the BSDs.
• thunderbird-patch-review by Marc Coquand allows a dev accustomed to GitHub to contribute without completely changing their approach.
• To test: configure an outgoing SMTP account, try git send-email on a trivial contribution (e.g., a typo in the kernel documentation, the LKML is surprisingly welcoming for clean first patches).
• Philosophical bonus: it's also a useful exercise in git literacy - understanding that the email patch and the git commit are almost the same object, which sheds a lot of light on git's behavior.