Linus Torvalds wrote: > > On Mon, 21 Nov 2005, Carl Baldwin wrote: > >>I have a question about automatic repacking. >> >>I am thinking of turning something like Linus' repacking heuristic loose >>on my repositories. I just want to make sure it is as safe as possible. >> >>At the core of the incremental and full repack strategies are these >>statements. >> >>Incremental... >> >>> git repack && >>> git prune-packed >> >>Full... >> >>> git repack -a -d && >>> git prune-packed > > > NOTE! Since that email, "git repack" has gotten a "local" option (-l), > which is very useful if the repositories have pointers to alternates. > > So do > > git repack -l > > instead, to get much better packs (and "-a -d" for the full case, of > course). > > Other that than, the old email suggestion should still be fine. i've been playing with "git repack" on StGIT-managed repositories. on NFS, using packs instead of individual objects is quite a bit faster, because a single NFS GETATTR will tell you if your NFS client's cached pack file is still valid, whereas a whole bunch of GETATTRs are required for validating individual object files. there are some things repacking does that breaks StGIT, though. git repack -d seems to remove old commits that StGIT was still depending on. git repack -a -n seems to work fine with StGIT, as does git prune-packed i'm really interested in trying out the new command to remove redundant objects and packs, but haven't gotten around to it yet. - 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
This archive was generated by hypermail 2.1.8 : 2005-11-22 16:27:30 EST