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

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 12, 2018, 13:41 UTC
Message-ID: <CACsJy8CUYosOGK5tn0C=t=SkbS-fyaSxp536zx+9jh_O+WNaEQ@mail.gmail.com>
In-Reply-To: <CACsJy8AWO5Vk-Qz3VVBUezWL=oAd9YkeGq=_TXGSb0GSs5bLcg@mail.gmail.com>

On Fri, Jan 12, 2018 at 7:07 PM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 7 quoted lines

>> 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