Synopsis
git send-email [--to <addr>] [--cc <addr>] [--cover-letter] <patch-or-dir>...Description
The git send-email command sends one or more patches via SMTP, each as a properly threaded email. It is the canonical tool for submitting patches to mailing-list-driven projects (Linux kernel, Git itself, U-Boot, etc.). It can read SMTP credentials from your Git config, prompt for them interactively, or use authentication files.
Patches are sent in order, with In-Reply-To headers connecting them into a single thread. The cover letter (if present) is sent first as the parent of the thread.
In day-to-day use, git send-email integrates closely with shell aliases, editor plugins, and continuous integration. Power users often add aliases that combine flags they always pass, or wrap the command in scripts that enforce team conventions. Output formatting can be customized via Git config — pretty formats, color schemes, and pager behavior are all tunable. When something goes wrong, the first diagnostic step is usually to re-run the command with GIT_TRACE=1 in the environment, which reveals the underlying plumbing calls. For unusual situations, the --help output (git send-email --help) opens the full manual page with details on every option, including those rarely used in casual workflows but essential for debugging or scripting at scale.
Understanding how git send-email interacts with the rest of Git's data model — the object database, the index, refs, and the working tree — pays dividends. Each command operates on some subset of these pieces, and knowing which it touches helps predict outcomes and recover from mistakes. Reading the official Git documentation alongside hands-on practice in a throwaway repository is the fastest way to internalize the nuances. Most production issues with Git stem from one of three causes: surprising default behavior, partial network operations, or rewriting history that was already shared. A working mental model of git send-email's side effects helps avoid all three.
Common Options
| Option | Description |
|---|---|
--to=<addr> | Primary recipient. |
--cc=<addr> | Carbon copy. |
--smtp-server=<host> | SMTP server (or sendmail path). |
--smtp-user=<user> | SMTP username. |
--annotate | Allow editing each patch before sending. |
--dry-run | Show what would be sent. |
--in-reply-to=<message-id> | Thread under an existing message. |
--confirm=<mode> | Confirmation behavior (always, never, cc). |
Examples
git send-email [email protected] *.patch
# Send all patches in CWD to a list
git send-email --cover-letter [email protected] \
[email protected] 0001-*.patch
# Series with cover letter, primary + cc
git send-email --dry-run --annotate -1 HEAD
# Preview a single patch without sending
git config --global sendemail.smtpServer smtp.gmail.com
git config --global sendemail.smtpServerPort 587
git config --global sendemail.smtpEncryption tls
# One-time SMTP configurationCommon Mistakes
Many corporate SMTP servers block plain SMTP — use TLS or app-specific passwords. Forgetting --cover-letter when sending a multi-patch series leaves reviewers without context. Sending a re-roll without --in-reply-to the original cover letter fragments the discussion.
Related Commands
git format-patch, git am, git request-pull, git config