On Wed, Jun 13, 2012 at 8:17 PM, Martin Fick <mfick@xxxxxxxxxxxxxx> wrote: > 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! [...] 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, <johan@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html