Re: git pull & git gc

[Junio C Hamano <gitster@pobox.com>]

On Wed, Mar 18, 2015 at 6:27 PM, Jeff King <peff@peff.net> wrote:
>
> Keeping a file that says "I ran gc at time T, and there were still N
> objects left over" is probably the best bet. When the next "gc --auto"
> runs, if T is recent enough, subtract N from the estimated number of
> objects. I'm not sure of the right value for "recent enough" there,
> though. If it is too far back, you will not gc when you could. If it is
> too close, then you will end up running gc repeatedly, waiting for those
> objects to leave the expiration window.
>
> I guess leaving a bunch of loose objects around longer than necessary
> isn't the end of the world. It wastes space, but it does not actively
> make the rest of git slower (whereas having a large number of packs does
> impact performance). So you could probably make "recent enough" be "T <
> now - gc.pruneExpire / 4" or something. At most we would try to gc 4
> times before dropping unreachable objects, and for the default period,
> that's only once every couple days.

We could simply prune unreachables more aggressively, and it would
solve this issue at the root cause, no?

We do keep things reachable from reflogs, so the only thing you are
getting by leaving the unreachables around is for an expert to perform
some forensic analysis---especially if there are so many loose objects
that are all unreachable, nobody sane can go through them one by one
and guess correctly if each of them is what they wished they kept if
their ancient reflog entry extended a few weeks more.

That is, unless there is some tool to analyse the unreachable loose
objects, collect them into meaningful islands, and present them in
some way that the end user can make sense of, which I do not think
exists (yet).