Re: [PATCH] gc: do not warn about too many loose objects

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jul 16, 2018, 20:56 UTC
Message-ID: <20180716205646.GF11513@aiede.svl.corp.google.com>
In-Reply-To: <20180716203539.GD25189@sigill.intra.peff.net>

Jeff King wrote:

> On Mon, Jul 16, 2018 at 01:21:40PM -0700, Elijah Newren wrote:
>> Jonathan Nieder wrote:

>>> My understanding is that exploding the objects is intentional behavior,
>>> to avoid a race where objects are newly referenced while they are being
>>> pruned.

[...]

Show 7 quoted lines

>> Ah, that's good to know and at least makes sense.  It seems somewhat
>> odd, though; loose objects that are two weeks old are just as
>> susceptible to being referenced anew by new commits, so the default of
>> running 'git prune --expire=2.weeks.ago' as gc currently does would
>> also be unsafe, wouldn't it?  Why is that any more or less unsafe than
>> pruning objects only referenced by reflog entries that are more than
>> 90 days old?

Part of the answer is that this safety feature applies even when reflogs are not in use. Another part is that as you say, you can start referencing an object at the same time as the reflog entry pointing to it is expiring.

[...]

Show 7 quoted lines

>                                    That's why we retain non-fresh
> objects that are referenced from fresh ones (so as long as you made the
> new commit recently, it transitively infers freshness on the old blob),
> and why we fresh mtimes when we elide a write for an existing object.
>
> That's _still_ not race-proof, because none of these operations is
> atomic.

Indeed. One of the advantages of using a packfile for unreachable objects is that metadata associated with that packfile can be updated atomically.

I don't believe we are very good at transitively propagating freshness today, by the way.

Thanks, Jonathan