Re: Filename quoting / parsing problem

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 2, 2010, 18:37 UTC
Message-ID: <7v8wcge4kr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <201001021236.26947.agruen@suse.de>

Andreas Gruenbacher <agruen@suse.de> writes:

Show 8 quoted lines

> On Friday 01 January 2010 09:01:19 pm Junio C Hamano wrote:
>> > Both "b file" and "c file " are parsed by "git apply" perfectly fine.
>
> Right, the "diff --git" lines are technically still parseable when the file 
> name stays the same.  With renames, lines like "diff --git a/f a/f b/f" or 
> "diff --git a/f b/f b/f" are possible, but then there will also be "renamed 
> from" and "renamed to" headers which will disambiguate things.  Still, it 
> doesn't seem like a good idea to allow such ambiguities in the first place.

You already realized that there is no ambiguity because "diff --git" lines are parsable and renames have explicit names. Why do you still maintain that we are allowing such "ambiguities" when there is none?

Show 5 quoted lines

>> Having said all that, I don't think we would mind a change to treat a
>> pathname with trailing SP a bit specially (iow, quoting "c file " in the
>> above failed attempt to reproduce the issue).
>
> I would prefer quoting file names which contain spaces anywhere,...

The only reason I said I don't think we would mind changing the trailing SP case is because the reduced risk of getting our patches corrupted by MUA _might_ outweigh the benefit of not quoting to avoid an eyesore [*1*].

But what you said would add to eyesore of quoted names (which you omitted from your quote) without any justification other than "I would prefer". The pros-and-cons in such a change is quite different; as we have already established that there is no ambiguity, "disambuguation" is not a "pro" in this comparison.

[Footnote]

*1* Strictly speaking, it is not just "an eyesore" that is an issue. Our diff output without renames are designed to be grokkable by other people's patch implementations (e.g. GNU patch), and the quoted pathnames are not understandable by them. Even though our final version of quoted path format came from the GNU diff/patch maintainer (back then, at least):

    http://article.gmane.org/gmane.comp.version-control.git/10103

I don't think it happened in the GNU land yet, and you would be the person to know about it ;-).