Re: `git status --porcelain` disagrees with documentation about quoting filenames with spaces

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 28, 2010, 23:41 UTC
Message-ID: <7vocad996g.fsf@alter.siamese.dyndns.org>
In-Reply-To: <EFFE2D68-BBA3-4EF4-B56A-AA4882EDE1E4@sb.org>

Kevin Ballard <kevin@sb.org> writes:

Show 10 quoted lines

> On Oct 28, 2010, at 11:44 AM, Junio C Hamano wrote:
>
>> Kevin Ballard <kevin@sb.org> writes:
>> 
>> [jc: why do you send messages with toooooooooooo loooooong lines sometimes
>> and normal line lengths some other times...?]
>
> I use a GUI mail client to write email. Anything I copy&paste is hard-wrapped,
> anything I write directly tends to not include hard linebreaks at all. Would it
> be better if I hard-wrapped my lines?

It is not better vs worse but is acceptable vs unacceptable, as hard wrapped messages have been the norm around here from day one. As far as I remember you only recently started sending messages with long lines, so I suspected perhaps you changed your environment and are doing so without realizing the pain you are causing to others.

> ... Granted, having " -> " in your pathname is also pretty
> insane, but my motivation here is just ensuring that the --porcelain format
> is parseable even if you are insane.

It is not just "also" but order of magnitude more insane ;-)

Just in case you misunderstood me, even though I think SP in path is already insane, I am sympathetic enough to them to stand behind 28fba29 (Do not quote SP., 2005-10-17); they were the ones who complained when they saw

    diff --git "a/My Documents/hello.txt" "b/My Documents/hello.txt"

and complained.  As

    diff --git a/My Documents/hello.txt b/My Documents/hello.txt

is perfectly parsable (and no, don't worry about renames---we have extra headers to keep them unambiguous), it is easier on their eyes if we did not quote these paths that are "normal" to them ;-)

>> The best would probably be to special case SP (which is normally not to be
>> quoted) _only_ in the context of "something" -> "something".
>
> That's what I was thinking. I'll look into doing just that.

Yeah, if we wanted to be perfect, it would be better to do so without causing unnecessary pain.