From: Jeff King <peff@peff.net>
Date: Sun, 13 Feb 2011 08:52:36 GMT
Subject: Re: a bug about format-patch of multibyte characters comment
Message-ID: <20110213085236.GA2251@sigill.intra.peff.net>
In-Reply-To: <4D579A35.1000007@gmail.com>

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.

> 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