[tz] [PATCH] More spelling and accent fixes.

[Paul Eggert]

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.