On Mon, Nov 10, 2014 at 8:31 PM, Jeff King <peff@xxxxxxxx> wrote: > On Mon, Nov 10, 2014 at 07:51:00PM +1100, Bryan Turner wrote: > >> Second change: git gc --auto now fails if there are loose empty blobs. >> >> We have a test which just touched empty files in objects/17 to trigger >> the gc --auto preconditions (Note: I realize this is completely >> invalid, and I've changed the test to no longer do this; I'm only >> surfacing the behavioral change). > > This is expected. As you noticed here: > >> error: object file >> .git/objects/17/02d54e8fba95ef9968a0c9b183fe22ec551c86 is empty >> fatal: unable to get object info for 1702d54e8fba95ef9968a0c9b183fe22ec551c86 >> error: failed to run prune > > the error comes from "git prune" failing. It is using unreachable but > "recent" objects as graph tips to keep around. If we can't load a tip > object, we abort the prune, because we would not want to delete objects > that might have been referenced (e.g., if it were a real corrupted > object that we could not read). > > The second behavior (die on broken objects) has been around for a while. > The new change (in the commit you bisected to) is that we are > considering more objects. > > I'll admit I didn't really consider the impact on sticking broken object > files into the object directory, but I think the code is doing the > sensible and safe thing. I agree. I wasn't aware this particular test was using such a questionable mechanism to trigger automatic garbage collection. I think the change to make git gc --auto more sensitive to this type of thing is definitely an improvement. As noted, I just wanted to surface the behavior change. Thanks again for your quick response! > > -Peff -- 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