On 03/19/16 08:52, David Woodhouse wrote: > If you're providing a message with -m on the comment line, then sure, > LC_CTYPE is correct. But when it comes from a file? Every file can come > from a different place, and can be in its *own* character set. I bet > you have *plenty* of text files on your system which aren't in latin2.
Probably. (I didn't create them though! ;)) > And if you're applying a patch with 'git-am' then the temporary file > storing the extracted message is almost *certainly* in UTF-8 or the > original charset from the email, not your LC_CTYPE. Right? git-am seems to work surprisingly well in this regard; I think. It seems to match git-format-patch. When you format a patch whose git-internal encoding is not UTF-8 (let's say, it's latin2), and the commit message actually digresses outside of ASCII, then the formatted patch email will receive: MIME-Version: 1.0 Content-Type: text/plain; charset=latin2 Content-Transfer-Encoding: 8bit This will make the message body display correctly in all MUAs. (The only snag, as I mentioned, is that the Cc: mail header that git constructs from the (otherwise correct) body-cc incorrectly becomes: =?UTF-8?q?QUOTED_PRINTABLE_LATIN2_BYTE_STRING?= <[email protected]> I.e., the embedded encoding identifier doesn't actually match the byte string. ) In turn, when git-am processes such a patch email, it picks up the charset from Content-Type, and passes it to git-commit as the commit-encoding. If I remember correctly. > Few people fully comprehend the true horror of the "simple" system they > try to cling to... My primary motivation is not the "simplicity" of single-byte encodings -- I agree with the quotes here. My primary motivation is this killer app called NEdit that I can't exist without. Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
