Command Reference

git-send-email Tutorial

Send patch series produced by `format-patch` through email while preserving commit boundaries and thread context.

Who This Is For
  • Developers who already know basic commit and branch actions
  • Readers who want to understand command boundaries and risk
Prerequisites
  • A basic mental model of worktree, index, and commits
  • Comfort reading `git status` and a small commit graph
Common Risks
  • Using local cleanup commands on already shared history
  • Continuing to rewrite before confirming a recovery path

The short version

git send-email sends patch series via email, preserving commit granularity and discussion threading.

Typical scenarios

  • mailing-list based contribution workflows
  • maintainer projects requiring patch-by-email
  • environments without direct hosted-platform access

Common companion flow

git format-patch -3 origin/main
git send-email *.patch

Generate patches first, then send.

Pre-send checklist

  1. SMTP/auth configuration works
  2. To/Cc recipients are correct
  3. thread conventions (subject prefix, reply chain) match project rules
  4. patch ordering and cover letter are complete

Safer send pattern

Dry-run or self-send before real list submission:

git send-email --dry-run *.patch

Frequent failure modes

  • encoding/line-wrap issues corrupt patch application
  • incorrect subject prefix violates list rules
  • missing one patch in a series breaks review/application continuity
Dry-run before real send

Once patches are mailed to public lists, correction cost rises quickly. Validate formatting and threading first.

Good follow-up reads

  1. git-format-patch
  2. git-request-pull
  3. open source fork pr contribution git send-email transmits patch files as emails to a mailing list or reviewer. It handles threading, encoding, and SMTP configuration — making it the delivery step after git format-patch has prepared the patches.

Typical use cases

  • Send a series of generated patch files to a project's mailing list: git send-email *.patch.
  • Use --to and --cc to direct patches to maintainers and interested reviewers.
  • Configure SMTP settings in .gitconfig so that sending patches becomes a repeatable, one-command step.

Diagram view

Patch email deliverysend-email reads .patch files and transmits them as properly formatted emails with threading, encoding, and SMTP handling.
Input
Patch files (.patch)SMTP configurationRecipient addresses
Output
Emails sent to recipientsThreaded patch series
Always do a dry run or test with a small scope first to verify recipients, threading, and encoding before the real send.

Special cases and boundaries

  • Do a dry run or small-scope test first so recipients, threading, and encoding are all correct before the real send.
  • SMTP credentials and server settings must be configured in .gitconfig or via command-line flags before sending.
  • send-email preserves the threading structure from format-patch, so patches arrive as a coherent email thread.
  • Some projects have specific patch submission guidelines (subject prefixes, sign-off requirements) — check the project's contribution guide before sending.

Related Reads

CommandsCore
git init Tutorial
CommandsCore
git clone Tutorial
CommandsCore
git status Tutorial

Previous / Next

Previousgit-format-patch TutorialCommandsNextgit-request-pull TutorialCommands