Re: 2.2.0-rc behavior changes (2/2)

From: Bryan Turner <bturner@atlassian.com>
Date: Nov 10, 2014, 10:45 UTC
Message-ID: <CAGyf7-E0KCqqceH_PmE1Tsm=2bR-Qin1RV9s-fJa6oY2zdTU8A@mail.gmail.com>
In-Reply-To: <20141110093128.GB11387@peff.net>

On Mon, Nov 10, 2014 at 8:31 PM, Jeff King <peff@peff.net> wrote:

Show 29 quoted lines

> 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