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