Re: What's cooking in git.git (Aug 2018, #02; Mon, 6)

Junio C Hamano [off-list ref] writes:

Hmph, it came from this message (most headers omitted)

    To:     =?iso-8859-1?Q?=C6var_Arnfj=F6r=F0?= Bjarmason [off-list ref]
    Message-ID: [ref]
    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 [off-list ref]

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.