Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html