Re: [PATCH] [RFC] Generational repacking

From: Dana How <danahow@gmail.com>
Date: Jun 7, 2007, 00:04 UTC
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:

Show 15 quoted lines

> 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