From: Erik Faye-Lund <kusmabite@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [BUG] format-patch does not wrap From-field after author name
Date: Fri, 15 Apr 2011 00:21:24 +0200 [thread overview]
Message-ID: <BANLkTikgZH8135=o5ODcA=780-1D7YFngw@mail.gmail.com> (raw)
In-Reply-To: <20110414214230.GB7709@sigill.intra.peff.net>
On Thu, Apr 14, 2011 at 11:42 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Apr 14, 2011 at 11:19:09PM +0200, Erik Faye-Lund wrote:
>> > 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.
>
Thinking about it a bit more, I'm getting a bit more unsure:
- The 78-limit is about user-interfaces, not protocol robustness.
- Since send-email unwraps the line and does not re-wrap it, even if
we have a name like this it's likely that the work gets undone right
away.
- So that means that send-email should probably also be fixed. But now
I'm wondering if we've crossed the point where this will just lead to
less obvious code for very little gain.
So I think I might have over-though this.
>> > [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.
Indeed. I have an itch around this area (I've been playing with
porting send-email to C), so I might look at it at some point soon.
> Because it means we have to _parse_ those
> headers and understand which part is a name and which is an address.
>
That part is surprisingly easy: If it contains a '<', then it's on the form
"Foo Bar Baz <foo@bar.baz>". If not, it's "foo@bar.baz" (assuming it's
UTF-8 encoded rfc5322 mailbox'es we assume, which would make the most
sense to me)
> 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).
>
I agree. I'm actually a tad surprised we support it in the first place.
next prev parent reply other threads:[~2011-04-14 22:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-14 17:01 [BUG] format-patch does not wrap From-field after author name Erik Faye-Lund
2011-04-14 17:12 ` Junio C Hamano
2011-04-14 17:50 ` Jeff King
2011-04-14 21:19 ` Erik Faye-Lund
2011-04-14 21:42 ` Jeff King
2011-04-14 22:18 ` Jeff King
2011-04-14 22:21 ` Erik Faye-Lund [this message]
2011-04-14 22:29 ` Jeff King
2011-04-14 22:43 ` Erik Faye-Lund
2011-04-15 3:30 ` Jeff King
2011-04-15 8:32 ` Erik Faye-Lund
2011-04-16 1:45 ` Jeff King
2011-04-14 17:52 ` Jeff King
2011-04-14 21:06 ` Erik Faye-Lund
2011-04-14 21:07 ` Erik Faye-Lund
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTikgZH8135=o5ODcA=780-1D7YFngw@mail.gmail.com' \
--to=kusmabite@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).