On Sun, Feb 13, 2011 at 05:45:41PM +0900, xiaozhu wrote: > >Shouldn't we still be generating "one two three", encoding it via > >rfc2047 if necessary, and _then_ deciding if folding is required? Yes, > >individual lines in a multi-line subject are good candidates for > >folding, but don't we need to be checking for and folding long lines > >anyway? > > It seems that by rfc2047 there is no multi-line subject spec. A subject > with multi-line will be always conflated to one single line. Sorry, I don't quite parse what you're saying. If the header takes up multiple lines, then yes, that gets decoded as a single line by rfc822 header folding. I would then expect that result to be rfc2047-decoded if necessary, and in theory it could contain encoded newlines. > And also that if we just generate the subject within multi-line just > like the current implemention, yes, we can modify the git-am to decode > it correctly, but most of the mail client will can not show it > correctly. Again, I don't quite understand what you're saying. The output generated by format-patch now is _not_ valid according to rfc2822. Changing git-am to parse its bogus output won't help that. > So it seems that there is only one way that combining the whole first > paragraph to a single line? But it will be a nightmare for some long comment. It's not the only way, but it is how we treat multi-line subjects in all other parts of git, so it is at least consistent (and that behavior was agreed upon after seeing what is worse: truncating to a single line, or merging lines). -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