As we know, we can periodically run git gc
to pack objects under .git/objects
.
In the case of a remote central Git repository (bare or not), though, after many pushes, there many files under myproj.git/objects
; each commit seems to create a new file there.
How can I pack that many files? (I mean the ones on the remote central bare repository, not on local clone repository.)
There won't be as much with git 2.11+ (Q4 2016) and a pre-receive hook.
In that scenario, you won't have to trigger a
git gc
at all.See commit 62fe0eb, commit e34c2e0, commit 722ff7f, commit 2564d99, commit 526f108 (03 Oct 2016) by Jeff King (
peff
).(Merged by Junio C Hamano --
gitster
-- in commit 25ab004, 17 Oct 2016)That temporary area will be set by the new environment variable
GIT_QUARANTINE_ENVIRONMENT
.That way, if a (big) push is rejected by a
pre-receive
hook, those big objects won't be laying around for 90 days waiting forgit gc
to clean them up.The remote repo should be configured to run gc as needed after a commit is made. See the documentation of gc.auto in git-gc and git-config man pages.
However, a remote repo shouldn't need all that much garbage collection, since it will rarely have dangling (unreachable) commits. These usually result from things like branch deletion and rebasing, which typically happen only in local repos.
So gc is needed more for repacking, which is for saving storage space rather than removing actual garbage. The gc.auto variable is sufficient for taking care of this.
While you should have some process that takes care of this periodically, automatically, it's no problem run
on a bare repository
This question should shed some light on how often you should run garbage collection.
The easiest option would be to use a scheduled task in windows or a cron job in Unix to run
git gc
periodically. This way you don't even need to think about it.