On Thu, Apr 14, 2011 at 11:19:09PM +0200, Erik Faye-Lund wrote: > > 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. :) > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html