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 matters). But it also d
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
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 right, which is a
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().
>
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 characters,
> that f
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 of
6 matches
Mail list logo
