From: Johan Herland Date: Wed, 13 Jun 2012 21:27:57 GMT Subject: Re: Keeping unreachable objects in a separate pack instead of loose? Message-ID: In-Reply-To: On Wed, Jun 13, 2012 at 8:17 PM, Martin Fick wrote: > Jeff King 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! [...] Just a +1 from me. We had the same problem at my former $dayjob, and worked around it by running a "git gc --prune=now" in the server repo (which is a command you'd rather not want to run in a server repo) to remove exploded loose objects. ...Johan -- Johan Herland, www.herland.net