Re: a bug about format-patch of multibyte characters comment

From: xiaozhu <xiaozhu@gmail.com>
Date: Feb 13, 2011, 10:14 UTC
Message-ID: <4D57AEFC.10608@gmail.com>
In-Reply-To: <20110213085236.GA2251@sigill.intra.peff.net>

On 2011/02/13 17:52, Jeff King wrote:

Show 15 quoted lines

> On Sun, Feb 13, 2011 at 05:45:41PM +0900, xiaozhu wrote:
>
>>> Shouldn't we still be generating "one two three", encoding it via
>>> rfc2047 if necessary, and _then_ deciding if folding is required? Yes,
>>> individual lines in a multi-line subject are good candidates for
>>> folding, but don't we need to be checking for and folding long lines
>>> anyway?
>>
>> It seems that by rfc2047 there is no multi-line subject spec. A subject
>> with multi-line will be always conflated to one single line.
>
> Sorry, I don't quite parse what you're saying. If the header takes up
> multiple lines, then yes, that gets decoded as a single line by rfc822
> header folding. I would then expect that result to be rfc2047-decoded if
> necessary, and in theory it could contain encoded newlines.

I am not similar with mail format. I read the rfc2047 again, but I didn't see any description about line separator encoding. Perhaps a base64 encoded-word will contain the line separator involuntarily? I also found a sample in rfc2047 it show us a line broken subject mail, but it didn't say any thing about line separator encoding.

Show 18 quoted lines

>> And also that if we just generate the subject within multi-line just
>> like the current implemention, yes, we can modify the git-am to decode
>> it correctly, but most of the mail client will can not show it
>> correctly.
>
> Again, I don't quite understand what you're saying. The output generated
> by format-patch now is _not_ valid according to rfc2822. Changing git-am
> to parse its bogus output won't help that.
>
>> So it seems that there is only one way that combining the whole first
>> paragraph to a single line? But it will be a nightmare for some long comment.
>
> It's not the only way, but it is how we treat multi-line subjects in all
> other parts of git, so it is at least consistent (and that behavior was
> agreed upon after seeing what is worse: truncating to a single line, or
> merging lines).
>
> -Peff

A sample of rfc2047 show us a legal line broken subject mail, like following:
------------------------------------------------------------------
  Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
     =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=
------------------------------------------------------------------

I understand that the current format-patch is not not valid to rfc2822/rfc2047, but even a valid one just like above, most of the mail client will can not show it correctly, they show the first line only, I think that's a problem of user friendliness.

-xzer