Re: [PATCH] generate a valid rfc2047 mail header for multi-line subject.

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 23, 2011, 17:34 UTC
Message-ID: <7vd3miac47.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110223080854.GB2724@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Yeah, I think the best path forward is:
>
>   1. Stop feeding "pre-folded" subject lines to the email formatter.
>      Give it the regular subject line with no newlines.

A bit of history. The original design of the pp_title_line() function since 4234a76 (Extend --pretty=oneline to cover the first paragraph, 2007-06-11) was to notice a multi-line paragraph and turn embedded newlines into line folds (this seems to be a breakage specific to non-ASCII titles).

As RFC 5322 (or 822/2822 for that matter) does not allow newlines in field bodies (2.2: A field body MUST NOT include CR and LF except when used in "folding" and "unfolding"...), it was the only way to allow the recipient to tell where the original line breaks were to fold at the line breaks in the original commit message. Then the recipient _can_ be git aware and turn the folding CRLF-SP into a LF, not just a SP, relying on the hope that the transport between the sender and the recipient would not clobber line folding, to recover the original.

The rebase pipeline (i.e. "format-patch | am") would have satisfied such a flaky assumption and that was the only reason I wrote the line folding on the output side that way. These days, however, "am" invoked in the rebase pipeline knows to slurp the message not from the patch text but from the original message, so we can safely depart form the original design rationale.

>   2. rfc2047 encoding should encode a literal newline. Which should
>      generally never happen, but is probably the most sane thing to do
>      if it does.

I was re-reading RFC 2047 and its 5. (3) [Page 8] seems to imply that this might be allowed: "Only printable and white space character data should be encoded using this scheme."; I think LF is counted as a white space character in this context, but it is a bit unclear.

If this "encode newline via 2047" _were_ allowed, I would say that my preference is not to go with your 1. above. Instead I would prefer to see us feed the entire first paragraph, whether it is a single-liner or multi-line paragraph, to the step 2 ...

>   3. rfc2047 should fold all lines at some sane length...

... and the have step3 fold its result to limit the physical length of the output line(s). Note that a multi-line first paragraph always will be encoded using 2047 because we cannot have a newline in the field body per RFC5322. But going the above route would allow us to recover the original first paragraph intact.

We might need to tweak the receiving end a bit, though. IIRC, mailinfo output assumed we will always be dealing with a single-liner subject.