Re: Keeping unreachable objects in a separate pack instead of loose?

> Jeff King <peff <at> peff.net> writes:
>> > Then, the creation of unreferenced objects from successive 'git add'
>> > shouldn't create that many objects in the first place.  They currently
>> > never get the chance to be packed to start with.
>>
>> I don't think these objects are necessarily from successive "git add"s.
>> That is one source, but they may also come from reflogs expiring. I
>> guess in that case that they would typically be in an older pack,
>> though.
> ...
>> That is satisfyingly simple, but the storage requirement is quite bad.
>> The unreachable objects are very much in the minority, and an
>> occasional duplication there is not a big deal; duplicating all of the
>> reachable objects would double the object directory's size.
> ...
> (I don't think this is a valid generalization for servers)
>
> I am sorry to be coming a bit late into this discussion, but I think there
>  is an even worse use case which can cause much worse loose object
> explosions which does not seem to have been mentioned yet:   "the
> server upload rejected case".  For example, think of a client pushing a
> change from the wrong repository to a server.  Since there will be no
> history in common, the client will push the entire repository and if for
>  some reason this gets rejected by the server (perhaps a pre-receive
> hook, or a gerrit server which says:  "way too many new changes..."),
> then the pack file may stay abandonned on the server.  When gc runs:
> boom the entire history of that other project will explode but not get
>  pruned since the pack file may be fairly new!