On 6/6/07, Sam Vilain <sam.vilain@xxxxxxxxxxxxxxx> wrote:
This is a quick hack at generational repacking. The idea is that you
successively do larger repack runs as the number of packs accumulates.
The commandline interface for this should be considered development
grade only, and of course there are no tests and very verbose output
:)
The useful invocation of this is git-repack -d -g
The -a option then becomes a degenerate case of generative repacking.
The intention is that this should end up light enough to be triggered
automatically whenever the (approximate) count of loose objects hits a
threshold, like 100 or 1000 - making git repositories "maintenance
free".
This patch complicates git-repack.sh quite a bit and
I'm unclear on what _problem_ you're addressing.
The recent LRU preferred pack patch
reduces much of the value in keeping a repository tidy
("tidy" == "few pack files").
Already git-gc calls git-repack -a -d. How do you plan to change this?
I wonder if you should be making git-gc more intelligent instead.
Also, you introduce a new pack properties file (.gen) which seems
awkward to me.
Perhaps something like this would be useful on a huge repository
under active use. But delta re-use makes full repacking quite quick for
a reasonably-sized repository already, and I don't see this being very useful
for a repository which is large due to large objects.
Thanks,
--
Dana L. How danahow@xxxxxxxxx +1 650 804 5991 cell
-
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
