Thread (1 message) 1 message, 1 author, 2016-06-15

Re: git stash takes excessively long when many untracked files present

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:58:25

Josh Triplett [off-list ref] writes:
quoted
I've already reverted the problematic patch to "git stash" and it
will not be part of the upcoming release.
Thanks!
quoted
Here is a quick attempt to see if we can do better in "ls-files -k".
Having said that, I am curious if the result of applying the patch
you are responding to, without reverting the "git stash" patch, is
now usable in the working tree you earlier had trouble with.
Sure, that works.  However, wouldn't it make sense to just directly let
git ls-files output to the screen, then test its return value (after
adding some ls-files option to set the return value)?
Not really.

We may want to add "exit early if we see even a single killed file"
option to the command so that we can simplify the "are we going to
abort" logic, but the error codepath that is executed after that
decision is made is not performance critical, and may need more
flexibility than always spewing everything that will be killed,
which could be thousands of crufts.  So I think using two separate
invocations to "ls-files --killed" is a necessity anyway.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help