Junio C Hamano <gitster@xxxxxxxxx> writes: > Hmph, it came from this message (most headers omitted) > > To: =?iso-8859-1?Q?=C6var_Arnfj=F6r=F0?= Bjarmason <avarab@xxxxxxxxx> > Message-ID: <20180804085247.GE55869@xxxxxxxxxxxxxxxxxxxxxxxxx> > Content-Type: text/plain; charset=iso-8859-1 > Content-Disposition: inline > Content-Transfer-Encoding: 8bit > > Subject: doc hash-function-transition: pick SHA-256 as NewHash > > ... > > Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> > > and the body seems to be correct iso-8859-1. "od -cx" tells me that > the file stores 0xf0 for that D looking thing, for example. Could it > be mailinfo that screws up, I wonder. A quick check with "git mailinfo" > does not give me anything suspicous---the info contents emitted to > its standard output is correctly converted to UTF-8. Puzzled... > > I read from public-inbox/git over nntp, if that matters. Just to close the loop, this turned out to be caused by my use of Gnus/Emacs. You can stop reading if you are not interested in reading and applying patches from inside Gnus. I am used to type '|' (gnus-summary-pipe-output) to pipe the current article into "git am -s[c3]", and it works fine when the payload is UTF-8. But the command decodes, and strips certain e-mail headers, before feeding it to the command. While the payload is converted to UTF-8 (presumably because that is what I use by default), "Content-type" is *not* among the e-mail headers that are stripped, so "am" ends up seeing UTF-8 bytestream that (still) claims to be "iso-8859-1" when processing the above message. I need to get used to typing M-i r | (that is, to use the 'r' "symbolic prefix") to force the message piped as-is to the command. Again, thanks for noticing and giving me a chance to correct the result before it got too late.
