Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)
On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote: > > Poor Simon Sandström. > > > > Funnily enough, this only exists for one commit. You've got several > > other commits from Simon that get his name right. > > > > What happened? > > I don't know what happened, I used git for this, I don't use quilt for > "normal" patches accepted into my trees anymore, only for stable kernel > work. > > So either the mail is malformed, or git couldn't figure it out, I've > attached the original message below, and cc:ed the git mailing list. > > Also, Simon emailed me after this was committed saying something went > wrong, but I couldn't go back and rebase my tree. Simon, did you ever > figure out if something was odd on your end? > > Git developers, any ideas? 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==?= If you de-base64 that, you get: =?UTF-8?q?Simon=20Sandstr=C3=B6m?= So something double-encoded it before it got to your mbox. -Peff ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)
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==?= > > > > Slightly related, once in a while I get funny emails through > git-commits-h...@vger.kernel.org, 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 de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/8] staging: et131x: Remove ununsed statistics
On Sat, Sep 13, 2014 at 08:45:56AM -0700, Greg KH wrote: > On Sat, Sep 13, 2014 at 12:37:46PM +0300, Dan Carpenter wrote: > > On Thu, Sep 11, 2014 at 10:59:42PM +0100, Mark Einon wrote: > > > >From struct ce_stats; unicast_pkts_rcvd, unicast_pkts_xmtd, > > > multicast_pkts_xmtd, broadcast_pkts_rcvd and broadcast_pkts_xmtd > > > > For some reason something adds a '>' to the start of lines which start > > with 'From'. I don't know what it is... > > It's an email protocol requirement, some RFC dictates it as "From" at > the start of the line is an email "start" flag. It's not an RFC thing. It's a side effect of the mbox format, which squashes together multiple messages with "From " lines to mark their starts. So many mbox implementations will quote them as ">From" (others introduce a Content-Length header, or are simply more careful about making sure that the line looks like a real "From " line, which should contain a date). If somebody's MUA is actually transmitting emails with the quoting, that's wrong. It is a local storage problem, and they should not be spreading the quoting disease to other systems. > > When I apply this patch with 'git am' then it just removes the From > > line. > > As it should :) That seems wrong. We should either leave it as-is (i.e., assume the writer used no quoting and really did mean ">From") or strip the ">" to turn it into "From" (i.e., assume the writer did use quoting). In some implementations, a literal ">From" gets quoted to ">>From" and so on. So we could even strip one level of quoting from such things (if we assume the writer was such an implementation). I don't think we can make this 100% foolproof without knowing which mbox variant the writer used. But dropping the line is probably the worst possible thing, as it does not match _any_ variants. :) -Peff ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
