On Fri, Jan 12, 2018 at 7:07 PM, Duy Nguyen <pclo...@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
