Neil Mayhew
2020-12-05 04:25:45
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.
Not necessarily. If we pushed a bugfix branch for several people to collaborate on it, then do a rebase when merging to master, we are essentially rebasing in remote. Even if we don't perform rebasing, the remote repo should still pack things up frequently so that new folks can Clone much faster.
@Ryuu, yes, you make a good point. This is one of the ways in which a remote repo could end up with loose objects. However, I did say "typically" when talking about rebasing. Maybe this scenario is becoming more common as people's use of git becomes more sophisticated. Even so, automatic garbage collection should take care of it eventually.
I think loose commits also result when doing a force push to overwrite the last commit push (?), but I could be wrong. Any thoughts?
@Sнаđошƒаӽ Yes, that creates loose objects. It comes under the heading of rebasing, and although that's not as common in remote repos, it still happens, especially with a pull-request workflow or any other workflow that allows users to have private branches on a remote repo that they can modify in a non fast-forward way. When I wrote this in 2010 GitHub was not as dominant as it is now.