diff options
Diffstat (limited to '')
| -rw-r--r-- | content/5/index.md | 49 |
1 files changed, 49 insertions, 0 deletions
diff --git a/content/5/index.md b/content/5/index.md new file mode 100644 index 0000000..799b159 --- /dev/null +++ b/content/5/index.md @@ -0,0 +1,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. |