Whole team gets 'too many unreachable loose objects' messages

Question

Not long ago, we have made the switch from SVN to Git.

A few days ago, I realized that all of our team gets those messages when they push :

$ git push
Counting objects: 32, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (19/19), done.
Writing objects: 100% (32/32), 2.94 KiB | 0 bytes/s, done.
Total 32 (delta 14), reused 0 (delta 0)
error: The last gc run reported the following. Please correct the root cause
and remove gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to remove them.

To [email protected]:root/xxx.git
   15c3bbb..69e6d8b  xxxx -> xxx

I thought it was coming from my computer for a while, until I realize that everybody has the same issues.

Needless to say, there is no gc.log in my .git folder, and using 'git gc' or 'git prune' has no effect.

So my question is : Could it be that the repository hosted on the server is somehow not clean? If so, how to I actually clean it?

All of the solutions I have found so far relate to local copies of repositories.

Also, we use Gitlab to host our repos.

EDIT : It is worth saying that I have since I posted this question also tried "Housecleaning" the repository using Gitlab but with no result so far.

Thanks

Answer 1

This is followed by issue 14357 (GitLab 8.6- or less)

The manual fix was:

• SSH into worker1
• cd into the gitlab-org/gitlab-ce directory
• ran rm gc.log, this just contained the line " warning: There are too many unreachable loose objects; run 'git prune' to remove them."
• ran git prune and prayed it didn't break things (which it thankfully didn't)

But it looks like, starting GitLab 8.7, auto gc is disabled.
This is also done in the context of (still opened) issue 13524:

Typically after a rebase, amend or other action that requires a force push we can have dangled commits.

Such "dereferenced" commits are getting lost due to git gc that may be executed internally or by using GitLab Housekeeping features.

If it happens that there was a discussion attached to a specific commit - it is not available after dereferenced commit has been garbage-collected.

Commits are being recorded in push events and are available through system notes added to merge request, and currently this produces error 500 in GitLab.

Update: that issue was closed a month later (July 2016) with:

• MR 5062: Don't garbage collect commits that have related DB records like comments

Makes sure a commit is kept around when Git garbage collection runs.
Git GC will delete commits from the repository that are no longer in any branches or tags, but we want to keep some of these commits around, for example if they have comments or CI builds.

• MR 4101: Refactor: Convert existing array-based diff refs to the DiffRefs model