Paolo Bonzini wrote (2008-05-13 07:08 +0200): > I think separate cutoffs should be in place for file size and number > of objects. Very tight packs probably require hours to repack as > efficiently. [...] > Thinking about both use cases, the best would be to have options > (common to git-clone, git-remote add, git-gc at least; and available > via config keys too) like > > --keep-packs[=THRES1,THRES2,...] Some thoughts from user interface's point of view. Two assumptions: - gc is daily or weekly operation - gc --aggressive is more like weekly or monthly operation. In big repositories gc can feel pretty slow if there are not any .keep packs and user runs the command daily. So I think there's a point in having a .keep pack in repositories the size of linux-2.6 for example. But at the same time I think it would be nice to have an easy UI-way to repack with better disk space optimization. This started as a crazy idea but maybe it's not so crazy so I'll rephrase my previous suggestion. At final stage the command gc --aggressive would add new .keep file which contains an identifier like This .keep file was added by "gc --aggressive" and will be automatically deleted at next run. (Or something like that, you get the idea.) At first gc --aggressive looks for .keep files with such identifier and deletes them if found. Then it proceeds normally and finally adds new .keep file with the same identifier. This way the "daily" gc would operate very fast (as it leaves .keep packs alone), and with gc --aggressive user could easily decide when to create new landmark .keep packs (and also prune possible dangling objects inside previous .keep packs). Normal user don't need to know the details. Just run gc occasionally and maybe gc --aggressive when better optimization is needed. How does this sound? -- 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
