On Tue, Feb 22, 2011 at 12:43:40PM -0800, Junio C Hamano wrote:
> So the general idea of this change (I am thinking aloud what should be in
> the updated commit log message as the problem description) is that:
>
> - We currently give an entire multi-line paragraph string to the
> add_rfc2047() function to be formatted as the title of the commit;
>
> - The add_rfc2047() functionjust passes "\n" through, without making it a
> folding whitespace followed by a newline, to help callers that want to
> use this function to produce a header line that is rfc 2822 conformant;
>
> - The patch introduces a new function add_rfc2047_multiline() that splits
> its input and performs line folding for such a caller (namely, the
> pp_title_line() function);
>
> - Another caller of add_rfc2047(), pp_user_info, is not changed, and it
> won't fold the name of the user that appear on the From: line.
>
> It is unclear if the last point is really the right thing to do, though.
> It is not a new problem that an author name that has a "\n" in it would
> break the output, but we probably would want to fix that case too here?
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).
I started to work on this, but got stuck on (3). Our existing wrap
functions want NUL-terminated strings, and we are operating on a
substring. I tried converting the wrap functions to handle lengths, but
it got way uglier than I had hoped. I think just strdup'ing the subject
temporarily is probably fine, though. Let me see what I can come up
with.
-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