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

From: Kevin Ballard <kevin@sb.org>
Date: Oct 29, 2010, 00:41 UTC
Message-ID: <CAA0934C-A48A-4E45-9875-7629BF6D909F@sb.org>
In-Reply-To: <7vocad996g.fsf@alter.siamese.dyndns.org>

On Oct 28, 2010, at 4:41 PM, Junio C Hamano wrote:

Show 14 quoted lines

>>> 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.

I apologize, I did not realize it caused a problem to others. I'm not used to interacting with people using terminal mail clients (e.g. mutt). I didn't give it much thought, but I just assumed the ML was hard-wrapping everybody's messages (of course this is obviously wrong, as evidenced by my own messages). I will bear this in mind for future emails.

Show 7 quoted lines

>>> 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.

Turns out it's fairly simple to do.

BTW, I'm trying an experiment here to see if I can just paste the patch into Mail.app without it being mangled. I sent it to myself first, and Mail.app is applying quoted-printable encoding to the patch, but it appears git-am can still understand it. Please let me know if this isn't acceptable and I will send it separately.

---8<---
Subject: status: Quote renamed/copied paths with spaces in short format

According to the documentation for git-status, in short output mode, paths with spaces or unprintable characters are quoted. However 28fba29 (Do not quote SP., 2005-10-17) removed the behavior that quotes paths that have spaces but not unprintable characters. Unfortunately this makes the output of `git status --porcelain` non-parseable in certain (rather unusual) edge cases. In the interest of removing ambiguity when parsing the output of `git status --porcelain`, restore the behavior of quoting paths with spaces but only for renamed/copied paths.

Signed-off-by: Kevin Ballard <kevin@sb.org>
---
wt-status.c |   10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index fc2438f..9624865 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -744,10 +744,20 @@ static void wt_shortstatus_status(int null_termination, struct string_list_item
		const char *one;
		if (d->head_path) {
			one = quote_path(d->head_path, -1, &onebuf, s->prefix);
+			if (*one != '"' && strchr(one, ' ') != NULL) {
+				putchar('"');
+				strbuf_addch(&onebuf, '"');
+				one = onebuf.buf;
+			}
			printf("%s -> ", one);
			strbuf_release(&onebuf);
		}
		one = quote_path(it->string, -1, &onebuf, s->prefix);
+		if (*one != '"' && strchr(one, ' ') != NULL) {
+			putchar('"');
+			strbuf_addch(&onebuf, '"');
+			one = onebuf.buf;
+		}
		printf("%s\n", one);
		strbuf_release(&onebuf);
	}

-- 
1.7.3.2.195.ge42d1.dirty