git send-email

format-patch + sendmail in one. Still the kernel's workflow.

🎯 What & why

Mails patches generated by format-patch through SMTP, threaded as a reply chain. Still the canonical workflow for the Linux kernel and many other mailing-list projects.

🧠 Mental model

Think of it as 'format-patch | sendmail' with proper threading and per-patch In-Reply-To headers wired up automatically. You point it at .patch files (or a revision range) and it sends them as a series.

🛠️ Synopsis

git send-email [<options>] <file|directory|rev-list-options>

Common flow:
  git format-patch -M origin/main -o outgoing/ --cover-letter
  $EDITOR outgoing/0000-cover-letter.patch
  git send-email --to=list@example.org outgoing/*.patch

🎚️ Switches & options

Flag	What it does
`--to=<addr>`	Primary recipient. Repeatable.
`--cc=<addr>`	Cc recipient. Repeatable. Often auto-filled from Cc: trailers in patches.
`--bcc=<addr>`	Bcc recipient. Repeatable.
`--in-reply-to=<msgid>`	Make the series a reply to an existing message-id (e.g. v1 thread).
`--smtp-server=<host>`	SMTP host (or sendmail binary path). Override sendemail.smtpServer.
`--smtp-user=<user>, --smtp-encryption=ssl\|tls`	Auth user and encryption. Pair with --smtp-pass or use a credential helper.
`--annotate`	Open each patch in $EDITOR before sending (last-chance review).
`--cover-letter`	When given a rev-range, generate and send a cover letter.
`--subject-prefix=<str>`	Override [PATCH] with [PATCH v2], [RFC], etc.
`--no-thread`	Send each patch as a standalone email, not threaded.
`--dry-run`	⚠️ Don't actually send; print what would happen. Use this first, every time.

💡 Use cases

Sending a patch series to LKML or any mailing-list-driven project.
Resending v2 of a series as a reply to the v1 thread via --in-reply-to.
Distributing patches to a small group of reviewers without a forge.
Scripted patch delivery from CI to a review list.

🧪 Examples

Dry run a series

git send-email --dry-run --to=list@example.org outgoing/*.patch

Actually send with cover letter

git send-email --to=maintainer@kernel.org --cc=list@vger.kernel.org outgoing/*.patch

Send v2 in reply to v1 thread

git send-email --in-reply-to='<20240101.123@example.org>' --subject-prefix='PATCH v2' outgoing/*.patch

One-off via Gmail SMTP

git send-email --smtp-server=smtp.gmail.com --smtp-encryption=tls --smtp-user=me@gmail.com --to=list@example.org 0001-fix.patch

🎓 Recommendations

Configure once in ~/.gitconfig under [sendemail] (smtpServer, smtpUser, smtpEncryption, from). Then commands are short.
Always run with --dry-run first. Mistakes here go to public mailing lists and live forever.
Use --annotate to add per-patch reviewer notes after the --- line; they won't end up in the commit.

🪤 Common pitfalls

Gmail and other providers often need an app password, not your account password.
Forgetting --in-reply-to on v2/v3 fragments the discussion across threads; reviewers hate this.
send-email auto-Ccs people from Signed-off-by/Cc trailers in the patches. Read the prompt before hitting 'y all'.

🔗 Related modules

📝 Quiz

Hit each option, then Check answers. Score is recorded; Next is always open.