Code Reviews Before GitHub: Git Patches via Email
Discover how developers conducted code reviews before GitHub using Git patches emailed to mailing lists. Learn the git format-patch, git send-email workflow that powered Linux kernel development with offline testing and inline feedback.
How did developers conduct code reviews before platforms like GitHub existed, especially when Git was available but online services like GitHub and GitLab were not yet available?
Developers relied on email-based workflows for code review, especially in projects like the Linux kernel, where Git was used locally to generate patches via git format-patch and send them inline with git send-email to mailing lists. Reviewers replied directly in email threads, providing feedback inline, while maintainers tested patches offline using git am before merging. This git code review process was lightweight, scalable, and threaded discussions kept everything organized without needing web platforms.
Contents
- Email-Based Code Review Origins
- Local Git Workflow for Patches
- Generating and Formatting Patches
- Sending Patches with Git Send-Email
- The Inline Review Process
- Applying and Iterating on Feedback
- Tools That Made It Work
- Why Email Outlasted Early Alternatives
- Sources
- Conclusion
Email-Based Code Review Origins
Picture this: it’s the mid-2000s. Git exists—Linus Torvalds just unleashed it in 2005—but no GitHub (2008) or GitLab in sight. How did teams review code without pull requests or web diffs? Simple: email. Developers emailed patches—those diff files showing exactly what changed—to public mailing lists. Everyone subscribed could reply, debate, and suggest fixes right in the thread.
This wasn’t chaotic. In the Linux kernel world, for instance, it handled thousands of patches weekly. A maintainer might scan their inbox, apply a patch locally in seconds, test it, and hit reply-all with “Looks good—applied.” No servers to load, no rate limits. As LWN explains, email let kernel devs process ~8 changes per hour from over 4,000 contributors. Faster than any web tool at scale.
And why patches? Before Git, even plain diff files worked, but Git supercharged it. You’d commit changes locally, then export them as clean, mailable patches. Bottom-posting kept replies tidy—new comments at the bottom, original code above.
Local Git Workflow for Patches
Git was king for local work, but reviews stayed offline. Clone the repo, hack away, then git commit -s to sign your work (that “-s” adds a Signed-off-by line, proving you agree to the Developer Certificate of Origin). No pushing to a central server—just generate patches.
What made this git code review shine? Everything stayed in Git’s ecosystem. Developers tested branches locally, rebased for cleanliness, then formatted patches to include commit messages, diffs, and metadata. It’s like pull requests, but emailed. Kernel newbies learned this fast: commit, format, send, repeat.
Threads unified it all. One email starts a series; replies build on it. Revisions? Tag them v2, v3—reviewers knew exactly where to jump in.
Generating and Formatting Patches
Ready to share? Fire up git format-patch. This command turns your commits into RFC822-formatted emails—perfect for mailing lists. Say you’ve got the last three commits: git format-patch HEAD~3. Boom: .patch files with subject lines like “[PATCH 1/3] Fix buffer overflow” and inline diffs.
Pro tip from the kernel docs: Always use --thread=shallow for series, adding a cover letter with git format-patch --cover-letter. It wraps everything neatly. Run ./scripts/checkpatch.pl first—catches style nits like lines over 80 chars or missing spaces.
Humans aren’t perfect, so tools helped. scripts/get_maintainer.pl scans your patch for who to CC: maintainers, relevant lists, even reviewers from past threads. Miss someone? Your patch dies in the inbox.
Sending Patches with Git Send-Email
No attachments—MIME kills threading. Instead, git send-email inlines patches as plain text. Dry-run it: git send-email --dry-run *.patch. Happy? Drop the flag, add --to maintainer@kernel.org --cc linux-kernel@vger.kernel.org.
From KernelNewbies, it’s straightforward: configure your SMTP in git config, then send. Patches arrive 72-column wrapped, bottom-posted, ready for review. GitHub pull requests? Fancy, but email scaled to massive projects without a single database query.
What if you’re on Windows? Cygwin or WSL worked fine. The barrier was low—anyone with Git and an email client could join.
The Inline Review Process
Inbox pings. Reviewer downloads the patch (or the whole thread as mbox), applies with git am. Builds? Tests? If yes, reply: “Reviewed-by: Foo Bar foo@bar.com”. Nitpick? Quote the bad line, suggest a fix below.
Discussions threaded naturally. One dev says “This hunk breaks x86_64,” another chimes in with a counterexample. No fragmented comments—just one conversation. As Bytelab notes, iterations used v2 patches resent in-reply, keeping history intact.
Maintainers triaged fast. Greg Kroah-Hartman once said email’s speed trumps GitHub for big projects—LWN backs that. No waiting for CI; apply locally, run tests offline.
Applying and Iterating on Feedback
Feedback lands? git am the review thread’s mbox to replay it. Tweak, re-commit, v2 it. Tools like b4 (modern helper) automate fetching, but back then, lore.kernel.org archives let you grab threads manually.
From a maintainer’s view, aliases like git review (difftool on patches) sped side-by-side checks. Build fails? Reject inline. Scales because it’s async—review at 2 AM, reply at lunch.
Iterations built trust. Tags like Acked-by piled up; maintainer pulls when ready.
Tools That Made It Work
No web UI, but scripts ruled. Checkpatch.pl for style, get_maintainer.pl for audience, patchwork for indexing threads (early LKML helper). git am -i interactively skipped cover letters.
Email clients? Thunderbird or mutt with Vim integration for inline edits. Patches as text meant grep, sed, diff worked anywhere. Older kernel docs stress plaintext—no HTML cruft.
This kit handled complexity. Multi-patch series? Numbered subjects kept order.
Why Email Outlasted Early Alternatives
GitHub dazzled with visuals, but email endured for kernels. Servers bottleneck at scale; email doesn’t. Offline-first: apply patches on your flight-delayed layover. Public lists meant anyone could review—no invites needed.
Even today, kernel sticks with it—platforms can’t match the velocity. William Durand’s experience shows: email’s threading beats fragmented GitHub comments. It’s battle-tested.
Sources
- Submitting patches: the essential guide to getting your code into the kernel
- Submitting patches (v4.16 docs)
- Why kernel development still uses email (LWN)
- Submitting your first patch to the Linux kernel (Bytelab)
- FirstKernelPatch (KernelNewbies)
- First patch in the Linux kernel (William Durand)
- How to apply patches from the Linux Kernel Mailing List
- My patch review workflow (Josef Bacik)
Conclusion
The email-patch model powered code review through Git’s early days, proving you don’t need web bells for solid git code review—just good tools and public lists. It scaled massive projects like Linux by keeping things fast, offline, and threaded. Today? Hybrids exist, but that foundation shaped modern workflows. Dive in with git format-patch—it’s still gold.