The problem of "git gc
" not removing all loose objects has been reported before (late 2008, ""git gc
" doesn't seem to remove loose objects any more"
git gc
only removes loose objects older than two weeks, if you really want to remove them now, run git prune.
But make sure no other git process can be active when you run it, or it could possibly step
on something.
"git gc
" will unpack objects that have become unreachable and were currently in packs.
As a result, the amount of disk space used by a git repository can actually go up dramatically after a "git gc" operation, which could be surprising for someone who is running close to full on their filesystem, deletes a number of branches from a tracking repository, and then does a "git gc" may get a very unpleasant surprise.
[
Example:]
Old branches are reserved via a tag such as next-20081204. If you update the your local copy of the linux-next repository every day, you will accumulate a large number of these old branch tags.
If you then delete a whole series of them, and run git-gc
, the operation will take quite a while, and the number of blocks and inodes used will grow significantly.
They will disappear after a "git prune
", but when I do this housekeeping operation, I've
often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
option to "git gc".
So in your case, would a "git prune
" be helpful?
(possibly with using "now" in the gc.pruneexpire
config variable, needed for the above behavior to happen).
You also have (from the same thread):
repack -a -d -l
Notice the lowercase 'a'.
git-gc
calls repack with uppercase 'A' which is what causes the unreachable objects to be unpacked. Little 'a', is for people who know what they are doing, and want git to just drop unreachable objects.