[MatthiasPortzel]

> Warning! Some people think that they can get away with sending patches through some means other than git send-email, but you can't.

Could someone elaborate on this? Obviously it’s not intended, but is there anything wrong, from a technical standpoint, with using `git format-patch`, zipping the result, attaching it to an email using a GUI email client, and sending it to a maintainer who unzips and runs `git am`?

[tlamponi]

The core reason for this is that lots (all?) of "modern" mail user agents (MUA) mess with whitespace in their default configuration, which breaks patches as the indentation is all of and git is confused.

git send-email is made for this, and handles all edge cases correctly, but depending on your MUA and/or it's config, it can work pasting patch diffs in there just fine – the point is that, especially for newcomers, and for a few edge cases, it may hard to do correctly and so using the tool made for the job avoids friction for all sites.

ps. ZIP wouldn't be required, just use base64 encoding, that's basically what git send-email does, depending on the encoding, line length, ... of a commit.

[diggan]

Zipping the patch kind of works around the issue but introduces probable workflow-incompatibilities, maintainers expect the patch itself in the email, not a compressed archive of the patch.

Re sending patches in email clients without using send-email, some clients (famously Outlook) try to be "helpful" and for example remove blank lines (double or single, don't remember) for example and will corrupt the patch in the process.

[bonzini]

The point is being able to discuss and archive things via email. Using a zip file makes this moot.

[catern]

That specific workflow precludes reviewing the patch via quoting and making inline comments, which is the normal way to review patches when sending them via email.