Re: [PATCH] git-repack: generational repacking (and example hook script)

From: Sam Vilain <sam@vilain.net>
Date: Jul 4, 2007, 00:05 UTC
Message-ID: <468AE462.1040202@vilain.net>
In-Reply-To: <alpine.LFD.0.999.0707031020300.26459@xanadu.home>

Nicolas Pitre wrote:

>> 1. Do you agree that some users would want their git repositories to be
>> "maintenance free"?
>
> I'm not so sure.

Well, no offence, but I think you should withhold from voicing a fundamental concern as this, because you're not one of its target users.

I'd be more than happy to reshape the patch so that it does not introduce this "complexity" into the current code path. Potentially it could entirely fit into the post-commit hook, which should not upset anybody as they don't have to turn it on. I just noticed that the "repack -a" code path was already doing a lot of what a generational repack would have to do, so thought I'd re-use the code.

Of course your critical analysis of code is more than welcome.

> And even if your developers are completely inept to the point of not 
> wanting to run 'git gc' once a week for example,

This kind of characterisation does not help the discussion.

> I'm sure you can automate 
> some of that maintenance asynchronously from a simple post commit hook 
> or something, based on the output of 'git count-objects -v'.

Yet another little command that I didn't know about that could make the
 patch simpler.

Potentially the calculations could be performed in count-objects. I'll investigate that.

Show 5 quoted lines

>> 2. Do you agree that having thousands of packs would add measurable
>> overhead?
> 
> Sure it would, but far less as it used to when we last discussed this 
> since performances in those cases has been improved significantly.

Far less for examining recent history. It would however make examining older history, and potentially blame operations slower. Just how much slower I don't know, but I'd guess that random access with 1000 small indices scanned sequentially is slower than with 10 larger indices.

> And if you end up with thousands of packs in the first place I think you 
> have a more fundamental problem to fix, something that generational 
> repacking would just paper over.

Right, but only if you are of the opinion that a repack is something that is best run off-line from normal work flow. If you want it to run in-line, then the fundamental problem would be "a simple operation now takes much longer because a huge repack is occurring".

So I think this fundamental decision is more of a user preference.

Sam.