整个团队收到“太多无法访问的松散对象"消息 [英] Whole team gets 'too many unreachable loose objects' messages

问题描述

不久前，我们已经从 SVN 切换到 Git.

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 [e-mail]: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.

不用说，我的 .git 文件夹中没有 gc.log，使用 'git gc' 或 'git prune' 没有任何效果.

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.

此外，我们使用 Gitlab 来托管我们的存储库.

Also, we use Gitlab to host our repos.

值得一提的是，自从我发布这个问题以来，我也尝试过大扫除".使用 Gitlab 的存储库，但到目前为止没有结果.

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.

推荐答案

接下来是 issue 14357(GitLab 8.6 或更低版本)

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

手动修复是:

• SSH 进入 worker1
• cd 进入 gitlab-org/gitlab-ce 目录
• 运行 rm gc.log，这仅包含行"警告:无法到达的松散对象太多；运行 'git prune' 删除它们."
• 运行 git prune 并祈祷它不会破坏东西(幸好它没有)

• 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)

但看起来，从 GitLab 8.7 开始，auto gc 已禁用.
这也是在 (仍然打开)问题 13524 的上下文中完成的:

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

通常在 rebase、amend 或其他需要强制推送的操作之后，我们可以进行 dangled 提交.

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

这样的取消引用"；由于 git gc 可能在内部执行或通过使用 GitLab 内务管理功能执行，提交正在丢失.

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.

提交记录在推送事件中，可通过添加到合并请求的系统注释获得，目前这会在 GitLab 中产生错误 500.

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.

更新:该问题在一个月后(2016 年 7 月)关闭:

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

• MR 5062:不要垃圾收集相关的提交数据库记录，如评论

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

确保在 Git 垃圾收集运行时保留提交.
Git GC 将从存储库中删除不再位于任何分支或标签中的提交，但我们希望保留其中一些提交，例如，如果它们有评论或 CI 构建.

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:重构:转换现有的基于数组的差异引用到 DiffRefs 模型
• MR 4101: Refactor: Convert existing array-based diff refs to the DiffRefs model

这篇关于整个团队收到“太多无法访问的松散对象"消息的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！