On Wed, 5 Sep 2007, Nix wrote:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html