Andreas Gruenbacher <agruen@xxxxxxx> writes:
> 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?
>> 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 ;-).
--
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