Paolo Bonzini <bonzini@xxxxxxx> wrote: > On 06/10/2010 08:04 PM, Shawn O. Pearce wrote: >> Joshua Jensen<jjensen@xxxxxxxxxxxxxxxxx> wrote: >>> Sometimes, 'git gc' runs out of memory. I have to discover which file >>> is causing the problem, so I can add it to .gitattributes with a >>> '-delta' flag. Mostly, though, the repacking takes forever, and I dread >>> running the operation. >> >> If you have the list of big objects, you can put them into their >> own pack file manually. Feed their SHA-1 names on stdin to git >> pack-objects, and save the resulting pack under .git/objects/pack. > > Do you know any simpler way than > > git log --pretty=format:%H | while read x; do > git ls-tree $x -- ChangeLog | awk '{print $3}' > done | sort -u > > to do this? I thought it would be nice to add --sha1-only to > git-ls-tree, but maybe I'm missing some other trick. Maybe git rev-list --objects HEAD | grep ' ChangeLog' pack-objects wants the output of rev-list --objects as input, file name and all. So its just a matter of selecting the right lines from its output. >> Assuming the pack was called pack-DEADC0FFEE.pack, create a file >> called pack-DEADC0FFEE.keep in the same directory. This will stop >> Git from trying to repack the contents of that pack file. >> >> Now run `git gc` to remove those huge objects from the pack file >> that contains all of the other stuff. > > That obviously wouldn't help if these large binaries are updated often, > however. No, it doesn't. But you still could do this on a periodic basis. That way you only drag around a handful of recently created large binaries during a typical `git gc`, and not the entire project's history of them. -- 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