Re: Stupid quoting...

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Wed, 13 Jun 2007, David Kastrup wrote:
>
>> what is the point in quoting file names and their characters in
>> git-diff's output?  And what is the recommended way of undoing the
>> damage?
>
> The recommended way is not using spaces to begin with. I mean, does 
> "David" contain spaces? People seem not to see the problem, and fail to 
> blame Microsoft for all the damage they have done, introducing that 
> stupid, stupid concept of filenames containing spaces, and _enforcing_ it.

Why are you talking about spaces ;-)?

There are a few things to note, but the first thing is that mere
spaces do not trigger quoting.  A tab (HT) does, so do non ASCII
characters.  The second thing is that we do this quoting for
various good reasons, and it is not likely to change.

As Alex mentions, the most safe way for programs to read is to
read from the -z format.  However, even if you are capable to do
so, it may be inconvenient in some languages (mainstream
languages like C and Perl are not among them).  Not quoting SP
is a conscious decision, as SP in filenames are rather common,
more common than non ASCII and much more common than HT.

The "raw" formats "ls-files -s", "ls-tree" and "diff --raw"
produce are designed to put names at the end, and typically
delimited with a HT, so that "lazy" scripts can use cut (whose
default delimiter is a HT) to pick out pieces from its output.
And plumbing tools reading from the standard input (most
notably, "update-index --stdin") know how to unquote them.  In
practice, not many people use non ASCII in pathnames and expect
them work sanely for everybody, so loosely written scripts, as
long as they cut at HT to pick out the pathname part, "mostly"
work (I think traditional core git scripts are safe, I suspect
some contributed ones shipped with git core may not be, Cogito
used to be very unsafe but it was audited and became much safer
before it got discontinued).

The pathname quoting rules in textual output was chosen
primarily to make diff output safer, as one of the most
important workflow git supports is e-mailable patches.

GNU patch treats HT on "+++ name"/"--- name" lines as the end of
name (and after HT comes timestamp), but the timestamp part is
treated as optional, which introduces ambiguities and confusion.
The issue was discussed some time ago (check the list archive
for discussion among I, Linus and Paul Eggert -- the GNU diff
and patch maintainer) and the quoting rules we use now is
consistent with what the diff and patch plan to use.  The update
on the GNU side may have already happened, it may not have.

When a patch appears in an e-mail, you would need to be aware
that not everybody has the luxury of living in UTF-8 only world.
Your commit message and cover letter may be in one encoding, the
pathnames that appear in diff headers may be in your filesystem
encoding, and the patch text that appear as the diff payload may
be in another document specific encoding.  All three could be
different (worse, a patch that touch more than one file can
carry different encodings in the payload part), and mixing
character set in a single piece of e-mail confuses people's MUA
and tends to mangle messages.  Quoting non ASCII characters in
pathnames, even they are perfectly valid and ordinary UTF-8
strings, is to eliminate one element in the above three as a
possible source of worries.