Re: [PATCH 1/2] mailinfo: support rfc3676 (format=flowed) text/plain messages

[Junio C Hamano <gitster@pobox.com>]

I really do not like this.

format=flowed instructs the receivers MUA that it is Ok to
reflow the text when the message is presented to the user.  That
is exactly what we do _NOT_ want to happen to patches.  Your
implementation may cleanly salvage what the sender intended to
send, but salvaging when applying the patch is too late.

You review the patch, decide to apply or reject, and then
finally apply.  Unmangling of corrupt contents should be done
before you review, not before you apply.

We have similar hacks to clean-up MIME attachments and CTE.
They are useful when your mailpath is not clean and can corrupt
contents even if you try to send it as text/plain in-line patch
as a fallback measure to ensure the contents not to get
corrupted.  format=flowed is completely opposite --- you are
giving your and recipients MUA freedom to reflow the text, but
there is no valid reason to allow that when sending patches.

We do not even encourage MIME attachments and ask senders to try
sending uncorrupt patch in-line, _even though_ MIME attachments
is a way to try harder not to corrupt the payload.  Why should
we encourage format=flowed which is meant to do the opposite
(i.e. we do not care about the exact content, we care more about
how better the paragraph looks and easier to read on screens
with different width)?

The format is not meant for the exact transmission of text (like
"patch") but more for paragraphed prose that can be re-fit on
narrower display like phones.  Section 5. even goes to say
"Hand-aligned text, such as ASCII tables or art, source code,
etc., SHOULD be sent as fixed, not flowed lines."

Side note.  I did not look at the patch very carefully, but can
you salvage a deleted text in the patch that removes a line that
consists of "- " (minus followed by a single space and then
end-of-line), or any deleted or added text that ends with a SP
without making them misinterpreted as "flowed" line for that
matter?

I even suspect that the sending MUA client may misbehave for
such a patch line.  In fact, doesn't section 4.2 say "a
generating agant should trim spaces before user-inserted hard
line breaks."?  It implies to me that you cannot have a fixed
line that ends with SP.

So just reject the patch when somebody sends you format=flowed
and ask them to re-send without =flowed, and the world will be
a much better place.