问题
Simple question, I'm trying to run git gc on a machine with a quota. Pre-gc, I'm at about 18GB of usage, almost all of which is my cloned git repository. My disk limit is 25GB. During the git gc operation, enough temporary files are written to disk to hit my limit and thus cause the git gc operation to fail.
I can delete the .git/objects/pack/tmp_pack_* after the failed operation and get back down to 18GB of usage, but I'd really like to actually complete git gc and reclaim a little performance.
Is there some fancy option (or series of other git commands) that I can use that doesn't involve first writing >7GB of temporary files to the disk?
回答1:
Which part of the gc is important for you? You could try running the git-prune and git-repack parts separately. With git-prune, be sure and specify a cutoff date with the --expire option. If there are a ton of loose objects in your repo, getting them out of the way first would be helpful.*
With git-repack, you can perhaps mess with the depth and window settings to get something small enough to run within the space you have.
* I don't pretend to fully understand all the issues involved, but I do notice that the prune comes after the repack in the git-gc code.
回答2:
Looks like the best solution is to ask IT for a bigger quota, though I'm still interested to hear workarounds. Today they were feeling generous, but tomorrow... :)
回答3:
git prune is an excellent suggestion, good call Jefromi.
Another thing you can do is compress your other files ; git gc; decompress.
7z gets amazing compression, but won't preserve hardlinks and Unix owner/group, IIRC. If you have a quota, the files are probably all owned by your account, so no worries on the first score. But the safest is tar c --lzma if you have it, or just tar czf or cjf. If you have a lot of small files, the umm, external(?) fragmentation up to block-size might be significant.
来源：https://stackoverflow.com/questions/1849959/git-gc-on-machine-with-quota