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

[Duy Nguyen <pclouds@gmail.com>]

On Fri, Jan 12, 2018 at 7:07 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> More generally, these hard limits seem contrary to what the user cares
>> about. E.g. I suspect that most of these loose objects come from
>> branches since deleted in upstream, whose objects could have a different
>> retention policy.
>
> Er.. what retention policy? I think gc.pruneExpire is the only thing
> that can keep loose objects around?

Er... I think I know what you meant now. Loose objects can come from
three sources: worktree (git-hash-object and friends),
git-unpack-objects and unreachable objects in packs released back by
git-repack.

The last one could be a result of a branch deletion like you said.
Depending on the branch size, you could release back a large amount of
objects in loose form at the same time. This really skews my "create
time distributed equally" model and the new estimation in
too_many_objects() probably won't help you much either. If only we
have a way to count all these objects as "one"... but putting these
back in a pack hurts obj lookup performance...
-- 
Duy