# When to repack? 5 messages from 2007-01-31 to 2007-01-31. Participants: Bill Lear, Jakub Narebski, Andreas Ericsson, Johannes Schindelin, Shawn O. Pearce. Thread: https://gitlist.dev/t/6591 ## Bill Lear, 2007-01-31 12:50 Subject: When to repack? Message-ID: <17856.37016.341839.397309@lisa.zopyra.com> URL: https://gitlist.dev/e/17856.37016.341839.397309%40lisa.zopyra.com ``` 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: % mv project project.pack % cd project.pack % GIT_DIR=. git repack -a -d % cd .. % mv project.pack project Bill ``` ## Jakub Narebski, 2007-01-31 12:58 Subject: Re: When to repack? Message-ID: URL: https://gitlist.dev/e/epq3nd%24pv5%241%40sea.gmane.org In-Reply-To: <17856.37016.341839.397309@lisa.zopyra.com> ``` [Cc: git@vger.kernel.org] 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: > > % mv project project.pack > % cd project.pack > % GIT_DIR=. git repack -a -d > % cd .. > % mv project.pack project Repack is safe. You can do it on live repository. It does the save under temporary name and move to proper place on it's own. By the way you can use "git --bare repack -a -d" instead of "GIT_DIR=. git repack -a -d" -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Andreas Ericsson, 2007-01-31 13:01 Subject: Re: When to repack? Message-ID: <45C09335.6010601@op5.se> URL: https://gitlist.dev/e/45C09335.6010601%40op5.se In-Reply-To: <17856.37016.341839.397309@lisa.zopyra.com> ``` 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: > > % mv project project.pack > % cd project.pack > % GIT_DIR=. git repack -a -d > % cd .. > % mv project.pack project > Renaming the directory isn't necessary. The packs won't be used until they have a .idx file. That .idx-file is written after the packfile, so any operations on the repo will simply use the old, loose, objects before the packing is completed. The worst thing that can happen is that an object about to be fetched is deleted in its loose version before the upload-pack program can open it, but that's no worse than having the entire directory being moved out from under it. On a side-note, this is a grade A example of something that should typically be done sunday night at 4am. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Johannes Schindelin, 2007-01-31 15:19 Subject: Re: When to repack? Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0701311617360.22628%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <45C09335.6010601@op5.se> ``` Hi, 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: > > > > % mv project project.pack > > % cd project.pack > > % GIT_DIR=. git repack -a -d > > % cd .. > > % mv project.pack project > > > > Renaming the directory isn't necessary. The packs won't be used until they > have a .idx file. That .idx-file is written after the packfile, so any > operations on the repo will simply use the old, loose, objects before the > packing is completed. > > The worst thing that can happen is that an object about to be fetched is > deleted in its loose version before the upload-pack program can open it, > but that's no worse than having the entire directory being moved out from > under it. 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. > On a side-note, this is a grade A example of something that should > typically be done sunday night at 4am. Actually, I'd recommend git-gc. It does not even call git-prune anymore, so there is no excuse. I even do it interactively very often, and I just love the fact that "gc" is so much shorter than "repack -a -d", _plus_ it also does other cleanup tasks. Ciao, Dscho ``` ## Shawn O. Pearce, 2007-01-31 15:36 Subject: Re: When to repack? Message-ID: <20070131153647.GA21888@spearce.org> URL: https://gitlist.dev/e/20070131153647.GA21888%40spearce.org In-Reply-To: ``` Johannes Schindelin 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. ```