Re: git gc --auto yelling at users where a repo legitimately has >6700 loose objects

From: Jeff King <peff@peff.net>
Date: Jan 13, 2018, 10:07 UTC
Message-ID: <20180113100734.GA30698@sigill.intra.peff.net>
In-Reply-To: <87d12f9lx1.fsf@evledraar.gmail.com>

On Fri, Jan 12, 2018 at 03:44:26PM +0100, Ævar Arnfjörð Bjarmason wrote:

Show 8 quoted lines

> More generally, the reason we even have the 2 week limit is to pick a
> good trade-off between performance and not losing someone's work that
> they e.g. "git add"-ed but never committed.
> 
> I'm suggesting (but don't know if this is worth it, especially given
> Jeff's comments) that one smarter approach might be to track where the
> objects came from (e.g. by keeping reflogs for deleted upstream branches
> for $expiry_time).

I don't think reflogs would help here. We consider reflog'd objects as "reachable". So you'd still have something like this:

  1. You delete a branch. Reflog still mentions its commits.

  2. You run gc (or auto-gc). Those objects are still retained in the
     main pack due to the reachability rule. This may happen multiple
     times, and each time their "timestamp" is updated, because it is
     really just the timestamp of the containing pack.

  3. 30 days later, you run another gc. The reflog is now past its
     expiration and is deleted, and now those objects are unreachable.
     This gc turns them loose, but it still considers them "recent" as
     of the last gc you ran, due to the timestamp thing above.

-Peff