Andreas Schwab wrote:
No, it isn't.
Sorry, my examples were wrong (I was confusing data with headers), and getting the examples right has helped me to understand the problem better. Here are the corrected examples: $ git format-patch a9da35214bd3a27d84458b8fee19d19c37aa67f0^! 0001-Further-updates-to-commentary-mostly-un-ASCII-fying-.patch $ git format-patch c25e1180cf3ec34d6c731d5ec16739d6d2ca8fc2^! 0001-More-spelling-and-accent-fixes.patch $ grep UTF-8 0* 0001-Further-updates-to-commentary-mostly-un-ASCII-fying-.patch:Content-Type: text/plain; charset=UTF-8 and the reason the first patch has a proper Content-type header and the second patch doesn't, is that git outputs the header only if the commit log message itself contains UTF-8.
See git-send-email(1).
The machine I email patches from is old (Solaris 10!) and slow and does not share files with my desktop. And my desktop does not use a mail transfer agent, for security reasons. So I've been running 'git format-patch' on my desktop, using scp to copy the output file to the email-sending machine, and feeding that file directly to /usr/lib/sendmail. Or, I've been using git format-patch to generate a file and then attaching the patch via Thunderbird. Apparently neither use case works with UTF-8 data, alas. What a pain.