On Fri, Feb 24, 2017 at 12:03:45PM +0100, Geert Uytterhoeven wrote: > > The problem isn't on the applying end, but rather on the generating end. > > The From header in the attached mbox is: > > > > From: =?us-ascii?B?PT9VVEYtOD9xP1NpbW9uPTIwU2FuZHN0cj1DMz1CNm0/PQ==?= <simon@xxxxxxxxxx> > > Slightly related, once in a while I get funny emails through > git-commits-head@xxxxxxxxxxxxxxx, where the subject is completely screwed up: > > Subject: \x64\x72\x6D\x2F\x74\x69\x6E\x79\x64\x72\x6D\x3A > \x6D\x69\x70\x69\x2D\x64\x62\x69\x3A \x53\x69\x6C\x65\x6E\x63\x65\x3A > ‘\x63\x6D\x64’ \x6D\x61\x79 \x62\x65 Sorry, I don't have a clue on that one. If you have UTF-8 or other non-ASCII characters in your subject, format-patch will correctly do the rfc2047 encoding (and it should always use QP). And that would kick in here because of the UTF-8 quotes. But that weird "\x" encoding is not in any mail standard I know of (and certainly Git would never do it). The odd thing is that the quotes themselves _aren't_ encoded. Just everything else. One other feature is that subject line is long enough (especially QP-encoded) that it spans two lines: $ git format-patch --stdout -1 b401f34314d | grep -A1 ^Subject Subject: [PATCH] =?UTF-8?q?drm/tinydrm:=20mipi-dbi:=20Silence:=20=E2=80=98?= =?UTF-8?q?cmd=E2=80=99=20may=20be=20used=20uninitialized?= It's possible that something along the way is mis-handling subjects with line-continuation (though why it would escape those characters, I don't know). > and some of the mail headers end up in the body as well: > > =?UTF-8?Q?\x75\x73\x65\x64_\x75\x6E\x69\x6E\x69\x74\x69\x61\x6C\x69\x7A\x65\x64?= That might be related to the whitespace continuation (the first line after the break is the second line of the subject). -Peff _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
