Jeff King <peff@xxxxxxxx> writes: > So that explains that bug (as a side note, you might think that if we > are flipping return values, lots of things would fail when they ask "do > we have this packed object" and it erroneously says "yes". But that does > not happen. The wrong return value comes from freshening the file, so we > only flip "yes" to "no", and never the opposite). > ... > When dt/cache-tree-repair is merged, we have a valid cache tree when we > run "git commit", and we realize that we do not need to write out the > tree object at all. Thus we never hit the buggy code, the object isn't > created, and the subsequent prune reports that there is nothing to > prune. Wow, that is a tricky "bug" (rather the series with the bug failed to fail when applied to 'master', so it is an "unbug" that hides a bug) to hunt down. Thanks for digging. -- 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