According to the manpage for git-status:
The fields (including the ->) are separated from each other by a single
space. If a filename contains whitespace or other nonprintable
characters, that field will be quoted in the manner of a C string
literal: surrounded by ASCII double quote (34) characters, and with
interior special characters backslash-escaped.
This is no longer true for filenames with spaces in them. I did some digging and I believe this changed 5 years ago in 28fba290 (Do not quote SP). My inclination is to say that the documented behavior should be restored, at least for the case of a copy/rename, simply for the sake of removing ambiguity in weird cases like the following:
> ls
a b
> git mv a 'a -> a with spaces'
> git status --porcelain
R a -> a -> a with spaces
Given that --porcelain is supposed to be machine-readable, this last line is unexpected, as it can be parsed in two different ways. Restoring the behavior of quoting filenames with spaces, at least for copies/renames, would fix this problem.
Given that the removal of quoting for filenames with spaces was an intentional change, does anybody have any strong opinions about whether we should restore the quotes in this scenario? The alternative is to simply change the documentation, but the un-parsability of the --porcelain format has me worried.
Note: this was prompted by a user on the #git IRC channel who was trying to parse the --porcelain format, specifically for parsing renames, and was surprised by the output not conforming to the documentation. I pointed him at the -z flag, but I still believe the non-z case should be fixed.
-Kevin Ballard--
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