Re: [PATCH] generate a valid rfc2047 mail header for multi-line subject.
- From
- xzer <xiaozhu@gmail.com>
- Date
- Feb 23, 2011, 15:16 UTC
- Message-ID
- <AANLkTimUXqKdTDcSVDK44XPhxWbHtQuDWHMED3PKqWE4@mail.gmail.com>
- In-Reply-To
- <20110223094844.GA9205@sigill.intra.peff.net>
2011/2/23 Jeff King <peff@peff.net>:
Show 27 quoted lines
> On Wed, Feb 23, 2011 at 03:08:54AM -0500, Jeff King wrote: > >> 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. >> >> 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. >> >> 3. rfc2047 should fold all lines at some sane length. As it is now, we >> may sometimes generate long lines in headers (though in practice, I >> doubt this is much of a problem). > > So here is a series that does this. It still doesn't preserve subject > newlines in "format-patch | am", but I don't think that was ever a goal > of the code. If we want to add it as an optional feature on top (maybe > as part of "-k"?), it should be easy to do (since the rfc2047 encoding > will now preserve embedded newlines). > > [1/3]: strbuf: add fixed-length version of add_wrapped_text > [2/3]: format-patch: wrap long header lines > [3/3]: format-patch: rfc2047-encode newlines in headers > > -Peff >
To the first point, I really want to find a way that we can remain the line breaker after import a formatted patch. That's why I add a new function to product multi line header, I want to do something which is special to subject. In my usage, I told my men every day that don't write too long in the first paragraph, but there are always somebody who forgets it, then I will get a patch with a very long subject just like a nightmare(yes, I gave them my temporary fix which I submitted here, so they can write as long as they want).
So I want to know whether we can generate a 2047 compatible header so that mailer can catch it correctly and the git-am can import it with line breaker correctly too.