Re: Bug - Status - Space in Filename

Jeff King writes: > Are there callers who don't just print the result? If not, we could just > always emit. That's slightly more efficient since it drops the expensive > strbuf_insert (though there are already so many copies going on in > quote_path_relative that it hardly

Re: Bug - Status - Space in Filename

On Fri, Nov 10, 2017 at 09:52:16AM +0900, Junio C Hamano wrote: > > That said, if this is the only place that has this funny quoting, it may > > not be worth polluting the rest of the code with the idea that quoting > > spaces is a good thing to do. > > Sounds sane. We can probably use a helper

Re: Bug - Status - Space in Filename

Jeff King writes: > Yeah, I think the original sin is using " -> " in the --porcelain output > (which just got it from --short). That should have been a HT all along > to match the rest of the diff code. The --porcelain=v2 format gets this > right. So we at lesat did something

Re: Bug - Status - Space in Filename

On Thu, Nov 09, 2017 at 12:26:20PM +0900, Junio C Hamano wrote: > The difference in d->head_path part is dealing about renames, which > is irrelevant for showing unmerged paths, but the key difference is > that the _unmerged() forgets to add the enclosing "" around the > result of quote_path(). >

Re: Bug - Status - Space in Filename

Joseph Strauss writes: > I believe I have found a bug in the way git status -s lists filenames. > > According to the documentation: > The fields (including the ->) are separated from each other by a single > space. If a filename contains whitespace or other nonprintable

RE: Bug - Status - Space in Filename

I believe I have found a bug in the way git status -s lists filenames. According to the documentation: 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