Re: git pull & git gc

[Jeff King <peff@peff.net>]

On Thu, Mar 19, 2015 at 07:31:48AM +0700, Duy Nguyen wrote:

> Or we could count/estimate the number of loose objects again after
> repack/prune. Then we can maybe have a way to prevent the next gc that
> we know will not improve the situation anyway. One option is pack
> unreachable objects in the second pack. This would stop the next gc,
> but that would screw prune up because st_mtime info is gone.. Maybe we
> just save a file to tell gc to ignore the number of loose objects
> until after a specific date.

I don't think packing the unreachables is a good plan. They just end up
accumulating then, and they never expire, because we keep refreshing
their mtime at each pack (unless you pack them once and then leave them
to expire, but then you end up with a large number of packs).

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.

-Peff