git-format-patch(1) if you
provide a revision list, oftentimes when submitting a patch series you should
git-format-patch(1) first, and later use
to submit the files it generated. There's a bunch of reasons for this.
send-emailis 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
If you use
--annotateor 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.
--composegets you a worse version of
--cover-letter. No diffstat is included by default, and the same problems as in 2) apply.
format-patchoutputs text files for you to browse and edit. This can be done on your own time and with your own tools, without the
send-emailprompt 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
Sadly, git-send-email.io still tells newcomers to
get-send-email(1), without even mentioning
This won't change 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 of Git's own contribution tutorial instead.