{"thread":{"id":"6591","subject":"When to repack?","startedAt":"2007-01-31T12:50:32Z","lastAt":"2007-01-31T15:36:47Z","messageCount":5,"participants":["Bill Lear","Jakub Narebski","Andreas Ericsson","Johannes Schindelin","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33123","messageId":"17856.37016.341839.397309@lisa.zopyra.com","threadId":"6591","inReplyTo":null,"subject":"When to repack?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-01-31T12:50:32Z","receivedAt":"2007-01-31T12:50:32Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"We have a company repo used by many people throughout the day. When/how\ncan I repack this? I have come to adopt this approach:\n\n% mv project project.pack\n% cd project.pack\n% GIT_DIR=. git repack -a -d\n% cd ..\n% mv project.pack project\n\n\nBill\n"},{"id":"33125","messageId":"epq3nd$pv5$1@sea.gmane.org","threadId":"6591","inReplyTo":"17856.37016.341839.397309@lisa.zopyra.com","subject":"Re: When to repack?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-31T12:58:37Z","receivedAt":"2007-01-31T12:58:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org]\n\nBill Lear wrote:\n\n> We have a company repo used by many people throughout the day. When/how\n> can I repack this? I have come to adopt this approach:\n> \n> % mv project project.pack\n> % cd project.pack\n> % GIT_DIR=. git repack -a -d\n> % cd ..\n> % mv project.pack project\n\nRepack is safe. You can do it on live repository. It does the save under\ntemporary name and move to proper place on it's own.\n\nBy the way you can use \"git --bare repack -a -d\" instead of \n\"GIT_DIR=. git repack -a -d\"\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33126","messageId":"45C09335.6010601@op5.se","threadId":"6591","inReplyTo":"17856.37016.341839.397309@lisa.zopyra.com","subject":"Re: When to repack?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-01-31T13:01:41Z","receivedAt":"2007-01-31T13:01:41Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Bill Lear wrote:\n> We have a company repo used by many people throughout the day. When/how\n> can I repack this? I have come to adopt this approach:\n> \n> % mv project project.pack\n> % cd project.pack\n> % GIT_DIR=. git repack -a -d\n> % cd ..\n> % mv project.pack project\n> \n\nRenaming the directory isn't necessary. The packs won't be used until they\nhave a .idx file. That .idx-file is written after the packfile, so any\noperations on the repo will simply use the old, loose, objects before the\npacking is completed.\n\nThe worst thing that can happen is that an object about to be fetched is\ndeleted in its loose version before the upload-pack program can open it,\nbut that's no worse than having the entire directory being moved out from\nunder it.\n\nOn a side-note, this is a grade A example of something that should typically\nbe done sunday night at 4am.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"33139","messageId":"Pine.LNX.4.63.0701311617360.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6591","inReplyTo":"45C09335.6010601@op5.se","subject":"Re: When to repack?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-31T15:19:49Z","receivedAt":"2007-01-31T15:19:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Jan 2007, Andreas Ericsson wrote:\n\n> Bill Lear wrote:\n> > We have a company repo used by many people throughout the day. When/how\n> > can I repack this? I have come to adopt this approach:\n> > \n> > % mv project project.pack\n> > % cd project.pack\n> > % GIT_DIR=. git repack -a -d\n> > % cd ..\n> > % mv project.pack project\n> > \n> \n> Renaming the directory isn't necessary. The packs won't be used until they\n> have a .idx file. That .idx-file is written after the packfile, so any\n> operations on the repo will simply use the old, loose, objects before the\n> packing is completed.\n> \n> The worst thing that can happen is that an object about to be fetched is\n> deleted in its loose version before the upload-pack program can open it,\n> but that's no worse than having the entire directory being moved out from\n> under it.\n\nAFAIR this case is handled gracefully by git. If the object it is still \naccessing moves to a(nother) pack, git will still find it.\n\n> On a side-note, this is a grade A example of something that should \n> typically be done sunday night at 4am.\n\nActually, I'd recommend git-gc. It does not even call git-prune anymore, \nso there is no excuse.\n\nI even do it interactively very often, and I just love the fact that \"gc\" \nis so much shorter than \"repack -a -d\", _plus_ it also does other cleanup \ntasks.\n\nCiao,\nDscho\n"},{"id":"33141","messageId":"20070131153647.GA21888@spearce.org","threadId":"6591","inReplyTo":"Pine.LNX.4.63.0701311617360.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: When to repack?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-31T15:36:47Z","receivedAt":"2007-01-31T15:36:47Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Wed, 31 Jan 2007, Andreas Ericsson wrote:\n> > Bill Lear wrote:\n> > > We have a company repo used by many people throughout the day. When/how\n> > > can I repack this? I have come to adopt this approach:\n> \n> AFAIR this case is handled gracefully by git. If the object it is still \n> accessing moves to a(nother) pack, git will still find it.\n\nNo AFAIR, its definately true. `git gc` is completely safe on a\nlive repository. Run it at will. Toss it in a cronjob. Whatever.\n\nWhat is *not* safe is `git gc --prune`. Don't run that on an\nactive repository.\n \n> > On a side-note, this is a grade A example of something that should \n> > typically be done sunday night at 4am.\n\nPossibly. Almost doesn't matter when you run it, except on very huge\nrepositories where the repack would take more than a few minutes.\n\nReally, just toss something like the following in a cronjob that\nruns once a week:\n\n\t#!/bin/sh\n\tfor g in /path/to/gits/*.git\n\tdo\n\t git --git-dir=\"$g\" gc\n\tdone\n\nIf you want to get fancy, use the output of `git count-objects -v`:\n\n\tcount: 325\n\tsize: 2332\n\tin-pack: 40894\n\tpacks: 1\n\tprune-packable: 0\n\tgarbage: 0\n\nI look for a count over 2000 or packs over 5. If either is true,\nI run gc, otherwise I skip that repository and leave it alone\nthat week. And that's actually packing more frequently than I\nreally need to. On any UNIX system you can probably let those go\nto >5,000 or 20 and still not really see a performance problem.\n\nIn general, repacks and network transfers (or basically any\noperation) takes longer as the number of loose objects increases\n(that's the count field in `git count-objects -v`). Keep below\n~2000 and `git gc` times tend to be measured in just a minute or\ntwo for even 200 MiB repositories.\n\n-- \nShawn.\n"}]}