On Wed, 5 Sep 2007, Nix wrote: > I personally wonder if git-gc shouldn't use a proportional scheme, so > that only some packs get repacked, maybe the smallest ones (and when > they grow to the same size as the next largest one, the two get repacked > into one). This has the singular advantage that you won't have to > carefully drop .keep files everywhere or have to worry about your git-gc > of 50K of loose objects suddenly deciding to repack 100Mb of packfiles > and taking ages. Not only that. Currently the "Counting objects" phase when running git-gc on the Linux repo takes a significant amount of time, even if there is little to repack. If any kind of automatic repack is implemented, it should be an incremental repacking only, not the full thing, i.e. git-repack without -a, or git-pack-objects with --unpacked. The idea is to be the least intrusive as possible. Also, object walking should be limited to objects linked to a commit object which is itself unpacked in order to cut on the time required to fully enumerate all objects. This way a semi-packed state will always be preserved and should be good enough. The full repacking should probably be left to manual execution of git-gc. Nicolas - 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
