Re: [Bug report] git status doesn't escape paths of untracked files

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 8, 2020, 01:17 UTC
Message-ID: <20200908011756.GG241078@camp.crustytoothpaste.net>
In-Reply-To: <CAMRL+qb0YC1EOTM-LDfMpJ=AJJ014LT5ufBcs0v77byN74A0vw@mail.gmail.com>

On 2020-09-08 at 00:28:57, Patrick Fong wrote:

Show 21 quoted lines

> What did you do before the bug happened? (Steps to reproduce your issue)
> touch "this is escaped"
> touch "this is not escaped"
> git add "this is escaped"
> git status --short
> 
> What did you expect to happen? (Expected behavior)
> I expected that git status --short would string escape both "this is
> escaped" and "this is not escaped" since they both contain spaces that
> need escaping.
> 
> What happened instead? (Actual behavior)
> git status did not string escape "this is not escaped" but it does if
> you add it to the index.
> 
> What's different between what you expected and what actually happened?
> 
> Anything else you want to add:
> Once you add "this is not escaped", git status will output it with
> quotes. git status --short seems to change its behavior of escaping
> based on whether the path is tracked or untracked.

git-status(1) says:

  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.

Note that that differs from the standard behavior of not handling spaces, which I expect is due to the need to handle renames unambiguously. We have some special handling in wt_shortstatus_status, but not in wt_shortstatus_other.

Patch incoming once the testsuite finishes running on this commit.

-- 
brian m. carlson: Houston, Texas, US