Re: When to repack?

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jan 31, 2007, 15:36 UTC
Message-ID: <20070131153647.GA21888@spearce.org>
In-Reply-To: <Pine.LNX.4.63.0701311617360.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 7 quoted lines

> On Wed, 31 Jan 2007, Andreas Ericsson wrote:
> > Bill Lear wrote:
> > > We have a company repo used by many people throughout the day.  When/how
> > > can I repack this?  I have come to adopt this approach:
> 
> AFAIR this case is handled gracefully by git. If the object it is still 
> accessing moves to a(nother) pack, git will still find it.

No AFAIR, its definately true. `git gc` is completely safe on a live repository. Run it at will. Toss it in a cronjob. Whatever.

What is *not* safe is `git gc --prune`.  Don't run that on an
active repository.

> > On a side-note, this is a grade A example of something that should 
> > typically be done sunday night at 4am.

Possibly. Almost doesn't matter when you run it, except on very huge repositories where the repack would take more than a few minutes.

Really, just toss something like the following in a cronjob that runs once a week:

	#!/bin/sh
	for g in /path/to/gits/*.git
	do
	  git --git-dir="$g" gc
	done

If you want to get fancy, use the output of `git count-objects -v`:

	count: 325
	size: 2332
	in-pack: 40894
	packs: 1
	prune-packable: 0
	garbage: 0

I look for a count over 2000 or packs over 5. If either is true, I run gc, otherwise I skip that repository and leave it alone that week. And that's actually packing more frequently than I really need to. On any UNIX system you can probably let those go to >5,000 or 20 and still not really see a performance problem.

In general, repacks and network transfers (or basically any operation) takes longer as the number of loose objects increases (that's the count field in `git count-objects -v`). Keep below ~2000 and `git gc` times tend to be measured in just a minute or two for even 200 MiB repositories.

-- 
Shawn.