David Kastrup [off-list ref] writes:
Junio C Hamano [off-list ref] writes:
quoted
If I were to create a patch between two versions of such a file, the
diff header would show the pathname encoded in one, and the changed
contents would ben shown in another. As long as you treat "git
diff" output as binary blob, that would work just fine, but when you
have to transmit such a diff in e-mail as an in-line patch, you
would have troubles.
ASCII-armoring of what amounts to binary files is the task of the mail
software. Also working with encodings. Escaping characters in the
diff headers but not in the file contents is not going to achieve
anything useful, anyway.
You misunderstood me. The issue is not about transmitting
without corruption. Armoring would make it impossible to
COMMENTING on the patch INLINE.
And that is where the pathname quoting git diff does originally
comes from.
On Sun, Jun 24, 2007 at 05:19:12AM -0700, Junio C Hamano wrote:
quoted
ASCII-armoring of what amounts to binary files is the task of the mail
software. Also working with encodings. Escaping characters in the
diff headers but not in the file contents is not going to achieve
anything useful, anyway.
You misunderstood me. The issue is not about transmitting
without corruption. Armoring would make it impossible to
COMMENTING on the patch INLINE.
And that is where the pathname quoting git diff does originally
comes from.
Then how about quoted-printable?
The point is that you're _already_ screwed by the fact that there can be
up to three different encodings in a patch (commit message, pathnames,
and file contents) but we only know one of them (the commit message).
With the other two, trying to convert encodings is pointless, since we
don't know the starting point. So we can either output them as-is as
binary, or use some sort of quoting mechanism.
The quoting that happens now is:
- sometimes unnecessary, and hurts people who are _not_ sending the
diff through the mail
- not recognized by any widely-used un-quoter. I can't comment on your
diff very well if it changes the file "\a/f\303\263\303\266", and
there's no viewer that will let me read that in a sane way.
I think David's point is that by doing the quoting at the MIME
level (using 8bit, or 7bit with QP), the recipient's MUA can at
least show the binary characters. Sure, that will totally break if
you are using a bad mismatch of encodings, but there's nothing we
can do to fix that, not knowing what the encodings are. At least it
_will_ work in the case that your encodings are the same.
The only argument I see _for_ the current quoting is for parsing by
non-mail programs (like patch or git-apply); in that case, it would seem
only necessary only to quote tab, newline, backslash, and double quote.
But at least those retain their human-readability.
-Peff