On Fri, Dec 16, 2016 at 04:40:16PM -0500, David Turner wrote:
> I would assume, based on the documentation, that auto gc would be doing
> an all-into-one repack:
> "If the number of packs exceeds the value of gc.autopacklimit, then
> existing packs (except those marked with a .keep file) are
> consolidated into a single pack by using the -A option of git
> repack."
>
> I don't have any settings that limit the size of packs, either. And a
> manual git repack -a -d creates only a single pack. Its loneliness
> doesn't last long, because pretty soon a new pack is created by an
> incoming push.
The interesting code is in need_to_gc():
/*
* If there are too many loose objects, but not too many
* packs, we run "repack -d -l". If there are too many packs,
* we run "repack -A -d -l". Otherwise we tell the caller
* there is no need.
*/
if (too_many_packs())
add_repack_all_option();
else if (!too_many_loose_objects())
return 0;
So if you have (say) 10 packs and 10,000 objects, we'll incrementally
pack those objects into a single new pack.
I never noticed this myself because we do not use auto-gc at GitHub at
all. We only ever do a big all-into-one repack.
> Unless this just means that some objects are being kept loose (perhaps
> because they are unreferenced)?
If they're unreferenced, they won't be part of the new pack. You might
accumulate loose objects that are ejected from previous packs, which
could trigger auto-gc to do an incremental pack (even though it wouldn't
be productive, because they're unreferenced!). You may also get them
from pushes (small pushes will be exploded into loose objects by
default).
-Peff