Why Do Billion-Dollar Projects Still Use Email to Receive Code?
If you’re used to the smooth “Create Pull Request” button on GitHub, sending code via email might feel like going back to… the Stone Age. Yet, giants like the Linux Kernel (with over 10,000 patches per release), Git, and PostgreSQL have stubbornly stuck with mailing lists for decades.
When I first started contributing to a small module in the Kernel, I spent an entire afternoon just struggling to configure the SMTP server. However, once I got the hang of it, I realized its brilliance. All discussions are neatly contained in an extremely lightweight email thread. You don’t need to open a heavy browser. More importantly, this process forces developers to polish every line of their commit messages, as that is the only thing that maintains context for the project 10-20 years down the line.
Let’s set up git send-email from scratch so you’re ready to send your first patch.
Quick Start: Sending Your First Patch in 5 Minutes
For those in a hurry, here is the shortest path to using Gmail as your patch “relay station.”
Step 1: Install the Tools
On Ubuntu or Debian, git send-email is usually not included in the default Git installation and resides in a separate package.
sudo apt update
sudo apt install git-emailStep 2: Configure SMTP (Gmail Example)
Note: You cannot use your primary Gmail password. Go to your Google account and create an App Password. Then, load the configuration into Git:
git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser [email protected]
# Use the App Password you just created here
git config --global sendemail.smtppass your-app-passwordStep 3: Create and Send the Patch
# Turn the last commit into a .patch file
git format-patch -1
# Send the patch to the maintainer
git send-email [email protected] 0001-fix-something.patchProfessional Workflow
To be a professional contributor, just knowing how to send isn’t enough. You need to understand how to organize a patch series so maintainers don’t ignore your contributions.
1. Writing “High-Value” Commit Messages
In the world of mailing lists, the commit message is the technical documentation. I often spend more time explaining “why” than “what.” Apply the 50/72 rule: a subject under 50 characters, and detailed content wrapped at 72 characters.
subsystem: description of the change
Detailed explanation of why this change is necessary.
Context, bug report links, and performance impact.
Signed-off-by: Your Name <[email protected]>Mandatory: Never forget the Signed-off-by line. This is a legal sign-off for the Developer Certificate of Origin (DCO), which the Linux Kernel is extremely strict about.
2. Using git format-patch
This command converts your commits into standard email format (RFC 2822). If you have a series of 5-10 commits, use the --cover-letter flag. It generates a 0000-cover-letter.patch file where you can write an overall summary of the changes, helping reviewers quickly grasp your goal.
3. Double-check with –annotate
Don’t rush to hit send. I always use the --annotate flag when running git send-email. It opens an editor (Vim/Nano) allowing you to review the email content and add notes below the --- line without affecting the official commit message.
Advanced: Managing Patch Revisions
It’s rare for a patch to be accepted on the first try. Maintainers will often ask for fixes or optimizations. At this point, you need to send Version 2 (v2), Version 3 (v3)…
Sending a New Version
Instead of manually renaming files, let Git handle it with the -v flag:
git format-patch -v2 HEAD~1The email subject will automatically change to [PATCH v2] .... This helps the maintainer’s mail filtering tools automatically group the patches together.
Using –in-reply-to
To keep the conversation threaded, send v2 as a reply to v1. Just copy the Message-ID from the old email and run:
git send-email --in-reply-to="[email protected]" v2-0001-fix.patchHard-Won Lessons and Common Rookie Mistakes
After being reminded by maintainers several times, I’ve gathered a few points to note to avoid looking unprofessional:
Never Send Patches via Webmail
Many people copy the patch file content and paste it into Gmail or Outlook. This is a fatal mistake. Browsers often automatically change whitespace (tabs to spaces) or wrap lines. A single incorrect space will break the patch, and the maintainer won’t be able to use the git am command to apply your code.
Run Automated Error-Checking Scripts
For the Linux Kernel, they provide a checkpatch.pl script. Before sending, run the following command:
./scripts/checkpatch.pl 0001-my-patch.patchIt will catch the smallest errors, such as trailing whitespace or incorrect indentation (the Kernel uses Tabs, not Spaces).
Conclusion
Getting used to git send-email might seem cumbersome at first, but it is your passport to the world of professional System Programming. It’s not just a tool; it trains you in disciplined thinking and standard technical communication. Good luck with getting your first patches merged into the world’s core projects!
