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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Hmph, it came from this message (most headers omitted)
>
>     To:     =?iso-8859-1?Q?=C6var_Arnfj=F6r=F0?= Bjarmason <avarab@gmail.com>
>     Message-ID: <20180804085247.GE55869@aiede.svl.corp.google.com>
>     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@gmail.com>
>
> 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.