On 2007.11.10 04:35:05 -0800, Brian Swetland wrote: > [Björn Steinbrink <B.Steinbrink@xxxxxx>] > > On 2007.11.10 02:14:20 -0800, Brian Swetland wrote: > > > > > > The example I have involves a coworker's name which needs non-ascii > > > characters. They are properly escaped in the From: line generated by > > > git-format-patch. git-send-email puts the generated From: line at the > > > top of the body of the email, unescapes it (to utf-8), and proceeds to > > > send the email with no Content-Type specified. > > > > You mean that it converts the header field to utf-8? It doesn't do that > > here (neither master nor 1.5.3.5) and IIRC that would be invalid anyway, > > because Content-Type applies to exactly that, content, not headers. Your > > sample has no non-ASCII characters (or at least I didn't see any), so > > git-send-email doesn't add a header to specify a charset. > > The first line of the patch is a From: field with Arve's name, in > an (rfc822?) encoded format): > From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@xxxxxxxxxxx> > > The mail generated by git-send-email makes this From: line the first > line of the *body* of the generated email. This line in the body > is no longer escaped, the utf8 characters are visible, but the header > of the message does not have a Content-Type indicating a non-ascii > encoding. Ah! Commit author differs from mail sender, didn't think of that. That's probably the same problem as with the -s option, ie. that git-send-email only looks at the existing text and not add anything it adds itself when checking the encoding. Sorry for the noise. Björn - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
