From: Junio C Hamano <gitster@pobox•com>
To: "Jay Soffian" <jaysoffian@gmail•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 1/2] mailinfo: support rfc3676 (format=flowed) text/plain messages
Date: Fri, 15 Feb 2008 22:57:50 -0800 [thread overview]
Message-ID: <7vodahcrrl.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <76718490802151037m87995c2gacf29667259eae41@mail.gmail.com> (Jay Soffian's message of "Fri, 15 Feb 2008 13:37:49 -0500")
"Jay Soffian" <jaysoffian@gmail•com> writes:
> On Fri, Feb 15, 2008 at 12:10 PM, Junio C Hamano <gitster@pobox•com> wrote:
>> 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.
>
> No, it indicates that the MUA sender mangled the message, but did so in
> a way that it can be unmanged* as long as the receiving MUA implements
> RFC 3676.
>
> * Trailing whitespace removed by the MUA before sending is the one
> exception that cannot be unmangled; I'll address this further below.
There is no way for you to address this other than brushing it
aside, saying "it does not matter". The information lost is
information lost.
> Existing code generally shouldn't have trailing whitespace nor
> whitespace only lines. ...
Says who?
We and the kernel folks are probably one of the more whitespace
strict projects, but I am sure both of us get our fair share of
patches that fix whitespace breakages while updating the
surrounding area. There are existing breakages, and also there
are lines that have deliberate trailing whitespaces.
Also, remember that this is not May 2005. git is not about the
kernel and git itself. We passed that point long time ago.
Other communities have different whitespace policies.
> ... However, let's say that it does and that the
> patch refers to one of these lines (either as context or a subtraction).
> In this case that hunk will fail to apply, unless we teach git-apply to
> be lenient if the only difference between the line in the patch and the
> existing code is trailing whitespace.
Failing to apply is not something I am worried about.
Silently applying bogosity is much more problematic, because it
would be _silent_, and "git am" is often used to apply hundreds
of patches in one go. We need to be able to trust the tool and
the tool should error out when there is any ambiguity.
> In the case of an addition, the patch *shouldn't* contain trailing
> whitespace anyway. If it did, git-apply would in its default
> configuration flag it as a whitespace error.
It just "warns". It does not strip by default. It should be a
conscious user decision (done with "am --whitespace=fix") and
the project policy.
>> 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.
>
> I don't get it. Why not accommodate fascist RFC 3676 MUAs if we can for
> the same reasons we accommodate QP, BASE64, and attachments instead of
> inline?
I need to ask people listening from the sidelines on the list
here. Was my explanation why MIME attachments and QP/BASE64 are
_fundamentally different_ from format=flowed insufficient?
The point is, format=flowed is _not_ meant for precise transfer
of the content matter. The design objective of format=flowed
lies elsewhere. It achieves nicer looking line-wrapping by
sacrificing the precise transfer of the content. It probably
does a very good job, allowing you to communicate with pals on
text-email enabled phones, although I do not have one so I
cannot judge ;-).
Attachments, QP and BASE64 are all about getting the contents as
intact as possible. Because they tend to make reviews harder,
git and the kernel community frown upon them. But our tools
tolerate them, because attachment is a fine or even preferred
way to transfer the patches in other circles.
But format=flowed is different. It loses information. Not just
one space at the end of the original line, but if you have very
long line that has more than one spaces at an unfortunate place,
the sending MUA can cut the line there and leave a single
trailing space for the receiving end to reflow.
RFC3676 may be a good text communication medium. It is just not
suitable for patch transfer. Just don't use it.
next prev parent reply other threads:[~2008-02-16 6:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-15 2:21 [PATCH 1/2] mailinfo: support rfc3676 (format=flowed) text/plain messages Jay Soffian
2008-02-15 2:21 ` [PATCH 2/2] test mailinfo rfc3676 support Jay Soffian
2008-02-15 11:01 ` Johannes Schindelin
2008-02-15 16:44 ` Jay Soffian
2008-02-15 10:41 ` [PATCH 1/2] mailinfo: support rfc3676 (format=flowed) text/plain messages Johannes Schindelin
2008-02-15 16:35 ` Jay Soffian
2008-02-15 18:43 ` Jay Soffian
2008-02-16 2:30 ` Johannes Schindelin
2008-02-15 17:10 ` Junio C Hamano
2008-02-15 18:37 ` Jay Soffian
2008-02-16 6:57 ` Junio C Hamano [this message]
2008-02-16 7:43 ` Jay Soffian
2008-02-16 9:59 ` Junio C Hamano
2008-02-16 14:34 ` Derek Fawcus
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=7vodahcrrl.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jaysoffian@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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