On Sun, Jun 24, 2007 at 05:19:12AM -0700, Junio C Hamano wrote:
> > 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
-
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
