From: Dana How <danahow@gmail.com>
Date: Thu, 07 Jun 2007 00:04:46 GMT
Subject: Re: [PATCH] [RFC] Generational repacking
Message-ID: <56b7f5510706061704r34692c49v994ff368bbc12d05@mail.gmail.com>
In-Reply-To: <11811281053874-git-send-email-sam.vilain@catalyst.net.nz>

On 6/6/07, Sam Vilain <sam.vilain@catalyst.net.nz> 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@gmail.com  +1 650 804 5991 cell