Josh Triplett <j...@joshtriplett.org> writes:
>> I've already reverted the problematic patch to "git stash" and it
>> will not be part of the upcoming release.
>> 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)?
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html