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 gcshould be called automatically called during “normal” use of a bare repository.I just ran
git gc --aggressiveon 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 gcon either repository.Smaller repository
Larger repository
I wish I had thought of it before I
gced these two repositories, but I should have rungit gcwithout the--aggressiveoption to see the difference. Luckily I have a medium-sized active repository left to test (164 commits over nearly 2 months).Running
git gcclearly made a large dent incount-objects, even though we regularlypushto andfetchfrom 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 gcmanually 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 gcmanually or setgc.autoto a lower value. My case for the question was simple curiosity, though.