Series-driven development

Many projects review patches by series, not by branch. You publish v1, get feedback, revise, send v2, repeat until merged. Git provides first-class tools for this loop.

Generating a series

git format-patch -o out/v1 main
git format-patch -o out/v1 --cover-letter --thread main
git format-patch -o out/v1 --subject-prefix='PATCH v1' main

Use --cover-letter to generate a 0000-cover-letter.patch you can edit with a series-wide intro. --thread wires Message-IDs together so mail clients display the series as a thread.

Sending

git send-email out/v1/*.patch \
  [email protected] \
  [email protected]

Configure SMTP once in ~/.gitconfig:

[sendemail]
smtpserver = smtp.example.com
smtpuser = [email protected]
smtpencryption = tls
smtpserverport = 587

Iteration

After feedback, revise via git rebase -i with autosquash, then publish v2:

git format-patch -o out/v2 --subject-prefix='PATCH v2' \
  --cover-letter --thread \
  --in-reply-to=<v1-message-id> main

Pre-fill the cover letter's diff between versions:

git range-diff main..v1 main..HEAD

Paste the output into the cover letter to show reviewers exactly what changed since v1.

Reroll prefix

git format-patch -v3 -o out/v3 main

The -v3 shorthand sets the subject prefix to PATCH v3 automatically.

Tracking acks

When reviewers reply with Reviewed-by or Acked-by, fold those trailers into the commits:

git interpret-trailers --in-place --trailer 'Reviewed-by: Alice <a@x>' <commit>

Common mistakes

Forgetting --in-reply-to on rerolls — the new series fails to thread under the old. Skipping the cover letter when sending three or more patches; reviewers want context. Not running ./scripts/checkpatch.pl or equivalent before send. Sending without testing on the project's expected base; configure format.useAutoBase.

Related

See "Git am: applying mailbox patches", "Git range-diff: comparing revision series", and "Generating and applying patches".