Re: [PATCH 3/3] format-patch: rfc2047-encode newlines in headers

On Wed, Feb 23, 2011 at 01:47:53PM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

These should generally never happen, as we already
concatenate multiples in subjects into a single line. But
let's be defensive, since not encoding them means we will
output malformed headers.

In this particular case, wouldn't it be more conservative and defensive to
produce malformed headers so that the patch won't leave the
originator?

No. If you go back to xzer's original mail, the malformed headers didn't
cause messages not to be sent. They just resulted in corrupted and
missing data on the receiver side. I don't think we can rely on any MUA
or MTA having a particular behavior for malformed mail. Some of them may
complain, but many won't.

I have a suspicion that mailinfo would choke on the output of this
one, even though I didn't try.

Actually, it does quite well. Without "-k", mailinfo turns it into a
single line, which is what I would expect. With "-k", the info file
contains:

  Author: Jeff King
  Email: peff@peff.net
  Subject: this is a long
  Subject: subject line with
  Subject: many lines in it
  Date: Wed, 23 Feb 2011 11:30:43 -0500

which "git am" turns back into the original multi-line subject.

So I think it's definitely the right thing to do. Not only does it avoid
us generating malformed mail, but because existing mailinfo handles it
sanely, it makes it easy to do a "preserve-newlines" patch on top (which
I'm still not sure is a great idea, but I can see the use in certain
circumstances).

-Peff