[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: When to repack?
From:       "Shawn O. Pearce" <spearce () spearce ! org>
Date:       2007-01-31 15:36:47
Message-ID: 20070131153647.GA21888 () spearce ! org
[Download RAW message or body]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]