1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
+++
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.
|
