+++
date = 2021-06-25T18:25:34+02:00
title = "Use git-send-email(1) only to send"

[taxonomies]
tags = ["git"]
+++

Even though [`git-send-email(1)`](https://git-scm.com/docs/git-send-email) calls
[`git-format-patch(1)`](https://git-scm.com/docs/git-format-patch) if you
provide a revision list, oftentimes when submitting a patch series you should
instead run `git-format-patch(1)` first, and later use `git-send-email(1)` only
to submit the files it generated. There's a bunch of reasons for this.

 1) `send-email` is built chiefly for mail submission, not patch formatting.
 There is no way to pass options meant for `format-patch`, meaning that
 you miss out on really good features like
 [`--cover-letter`](https://git-scm.com/docs/git-format-patch#Documentation/git-format-patch.txt---no-cover-letter)
 or
 [`--interdiff`](https://git-scm.com/docs/git-format-patch#Documentation/git-format-patch.txt---interdiffltpreviousgt).

 2) If you use
 [`--annotate`](https://git-scm.com/docs/git-send-email#Documentation/git-send-email.txt---annotate)
 or decide to edit the mail body, you will lose all changes if you quit before
 sending. You can't save your work and continue writing the mail later either.
 Once you call `send-email`, you're committed; It's all or nothing.

 3) [`--compose`](https://git-scm.com/docs/git-send-email#Documentation/git-send-email.txt---compose)
 gets you a worse version of `format-patch`'s `--cover-letter`. No diffstat is
 included by default, and the same problems as in 2) apply.

 4) `format-patch` outputs text files for you to browse and edit. This can be
 done on your own time and with your own tools, without the `send-email` prompt
 nagging and stressing you.

Providing a convenient way of quickly sending out small patches makes sense, but
all in all I think the inclusion of formatting in `git-send-email(1)` is a
glaring misfeature. Hiding `git-format-patch(1)` away from the user makes
`git-send-email(1)` intransparent and, worse, really clunky to use for regular
patch workflows.

Sadly, [git-send-email.io](https://git-send-email.io/) still tells newcomers to
use **only** `get-send-email(1)`, without even mentioning `git-format-patch(1)`.
This [won't change](https://lists.sr.ht/~sircmpwn/sr.ht-dev/%3C20200925224503.10032-1-evan.gates%40gmail.com%3E#%3CC5WTCDJYQZGF.22D6HCBBU9T82@homura%3E) any time soon, either.

That is a shame. Guiding people to a worse workflow will not increase the
standing of mail-based processes. For now I'd recommend linking newcomers [this
section](https://git-scm.com/docs/MyFirstContribution#howto-git-send-email) of
Git's own contribution tutorial instead.