On Tue, 11 Aug 2009, Hin-Tak Leung wrote: > On Wed, Aug 5, 2009 at 11:39 PM, Nicolas Pitre<nico@xxxxxxx> wrote: > > Anyway... To solve your problem, you simply need to run 'git gc' with > > the --prune=now argument to disable that grace period and get rid of > > those unreferenced objects right away (safe only if no other git > > activities are taking place at the same time which should be easy to > > ensure on a workstation). The resulting .git/objects directory size > > will shrink to about 441 MB. If the gcc.gnu.org git server was doing > > its job properly, the size of the clone transfer would also be > > significantly smaller, meaning around 414 MB instead of the current 600+ > > MB. > > > > And BTW, using 'git gc --aggressive' with a later git version (or > > 'git repack -a -f -d --window=250 --depth=250') gives me a .git/objects > > directory size of 310 MB, meaning that the actual repository with all > > the trunk history is _smaller_ than the actual source checkout. If that > > repository was properly repacked on the server, the clone data transfer > > would be 283 MB. This is less than half the current clone transfer > > size. > > > > > > Nicolas > > > > 'git gc --prune=now' does work, but 'git gc --prune=now --aggressive' > (before) and 'git gc --aggressive' (after) both create very large > (>2GB; I stopped it) packs from the ~400MB-600MB packed objects. I > noted that you specifically wrote 'with a later git version' - > presumably there is a some sort of a known and fixed issue there? Just > curious. >From git v1.6.3 the --aggressive switch makes for 'git repack' to be called with --window=250 --depth=250, meaning the equivalent of: git repack -a -d -f --window=250 --depth=250 Do you still get a huge pack with the above? > I guess --aggressive doesn't always save space... If so that is (and was) a bug. Nicolas -- 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