Re: [BUG] format-patch does not wrap From-field after author name

From: Jeff King <peff@peff.net>
Date: Apr 14, 2011, 21:42 UTC
Message-ID: <20110414214230.GB7709@sigill.intra.peff.net>
In-Reply-To: <BANLkTin+K46_RSDsYWHso3v7Gpe_k+0m8Q@mail.gmail.com>

On Thu, Apr 14, 2011 at 11:19:09PM +0200, Erik Faye-Lund wrote:

Show 7 quoted lines

> > Note that it relies on the commit header having a space before the "<",
> > which forms the continuation whitespace for the header. This is probably
> > reasonable, but we could double-check if we want to handle malformed
> > commit headers better.
> 
> I think that's a reasonable assumption; this field comes straight from
> the commit. It should already be well-formed, no?

Probably; it was just something I noted while writing the patch, and I like to be paranoid about assumptions. :)

Show 7 quoted lines

> > Or we could just ignore it. AFAICS, this doesn't actually violate
> > rfc2047, nor rfc5322. The 78-character limit is simply a SHOULD, and
> > we have up to 998 for MUST. For a single-address header[1], this seems
> > kind of unlikely to me.
> 
> True. But since the fix is as simple as it is, perhaps it's worth it
> just for the clean conscience?

Fair enough. Patch to follow.

> > [1] For multi-address headers like "format-patch --cc=foo --cc=bar", it
> > looks like we already break them across lines.
> 
> Yes, but this is even worse: these fields don't get encoded at all!

Ugh, you're right. That is a totally separate issue, and one I really don't want to get into. Because it means we have to _parse_ those headers and understand which part is a name and which is an address.

People who use "--cc" or format.headers will have to deal with that themselves. I consider both to be somewhat useless, since you can post-process the mbox after format-patch is run (or in your MUA). Whereas quoting and encoding fields in format-patch is necessary to give unambiguous input to the MUA (be it send-email or whatever).

-Peff