man git-gc
doesn't have an obvious answer in it, and I haven't had any luck with Google either (although I might have just been using the wrong search terms).
I understand that you should occasionally run git gc
on a local repository to prune dangling objects and compress history, among other things -- but is a shared bare repository susceptible to these same issues?
If it matters, our workflow is multiple developers pulling from and pushing to a bare repository on a shared network drive. The "central" repository was created with git init --bare --shared
.
As Jefromi commented on Dan's answer,
git gc
should be called automatically called during "normal" use of a bare repository.I just ran
git gc --aggressive
on two bare, shared repositories that have been actively used; one with about 38 commits the past 3-4 weeks, and the other with about 488 commits over roughly 3 months. Nobody has manually rungit gc
on either repository.Smaller repository
Larger repository
I wish I had thought of it before I
gc
ed these two repositories, but I should have rungit gc
without the--aggressive
option to see the difference. Luckily I have a medium-sized active repository left to test (164 commits over nearly 2 months).Running
git gc
clearly made a large dent incount-objects
, even though we regularlypush
to andfetch
from this repository. But upon reading the manpage forgit config
, I noticed that the default loose object limit is 6700, which we apparently had not yet reached.So it appears that the conclusion is no, you don't need to run
git gc
manually on a bare repo;* but with the default setting forgc.auto
, it might be a long time before garbage collection occurs automatically.* Generally, you shouldn't need to run
git gc
. But sometimes you might be strapped for space and you should rungit gc
manually or setgc.auto
to a lower value. My case for the question was simple curiosity, though.