在 git svn clone/fetch 期间避免“警告:有太多无法访问的松散对象”

Posted

技术标签:

【中文标题】在 git svn clone/fetch 期间避免“警告:有太多无法访问的松散对象”【英文标题】:Avoiding "warning: There are too many unreachable loose objects" during git svn clone/fetch 【发布时间】:2016-06-14 19:14:36 【问题描述】:

当针对大型 Subversion 存储库(100k+ 次提交)运行 git svn clonegit svn fetch 时,提取会定期停止:

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause and remove .git/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.

gc --auto: command returned error: 255

为了恢复,我必须按照说明进行操作,运行更激进的 prune 和 gc,删除日志文件并继续,只是在读取另一批 10k 提交后再次发生。

如何避免这个问题?

【问题讨论】:

【参考方案1】:

我认为如果您将配置选项gc.pruneExpire 设置为now,至少在导入期间是暂时的,它将避免该消息。设置该选项后,git gc 将立即删除 所有 个无法访问的对象,而不是仅删除至少两周前的对象(默认值)。再加上 gc.auto 的合理值,这应该可以防止它们累积到您收到该消息的程度。

【讨论】:

【参考方案2】:

自我回答。

git svn 操作属于启动后台gc --auto 内务操作的操作。在这种情况下,我认为git svn fetch 的持续进展可能会导致gc 操作中某个时间点的unreachable/loose objects 数量超过auth-threshold,从而导致此警告。不幸的是,这对于正在进行的提取来说是致命的。

我的解决方案是暂时禁用/怀疑这些 gc 操作,方法是按照其手册页中的说明停用 gc auto:

git config gc.auto 0

git svn fetch 操作完成后,您可以根据需要删除此配置,并运行手动完整 gc、修剪和重新打包操作以优化最终存储库。

【讨论】:

【参考方案3】:

开始在 git pull 上看到这个警告:

$ git pull
remote: Enumerating objects: 22, done.
remote: Counting objects: 100% (22/22), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 22 (delta 17), reused 22 (delta 17), pack-reused 0
Unpacking objects: 100% (22/22), done.
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove .git/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.

Already up-to-date.

查看警告文件,内容不多:

$ cat .git/gc.log
warning: There are too many unreachable loose objects; run 'git prune' to remove them.

阅读帮助:

$ git help gc

听起来我们应该定期做一些这样的事情

运行偶尔推荐的激进选项

$ git gc --aggressive
Counting objects: 41544, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (40544/40544), done.
Writing objects: 100% (41544/41544), done.
Total 41544 (delta 30536), reused 7801 (delta 0)
Removing duplicate objects: 100% (256/256), done.
Checking connectivity: 46959, done.

删除日志警告:

$ rm .git/gc.log 

微笑

:)

【讨论】:

【参考方案4】:

请注意,在这种情况下,删除.git/gc.log 是解决方案,删除会更容易。

在 Git 2.34(2021 年第四季度)中,建议消息中的路径名已准备好进行剪切和粘贴。

参见Ævar Arnfjörð Bjarmason (avar)commit b45c172(2021 年 8 月 31 日)。(由 Junio C Hamano -- gitster -- 合并于 commit 02d2632,2021 年 9 月 10 日)

gc:从“gc.log”行中删除尾随点

签名人:Ævar Arnfjörð Bjarmason建议人:Jan Judas

从我们发出的关于 gc.log 的警告中删除尾随点。 各种终端用户体验通常允许用户选择“单词”,并且通过包含尾随点,用户想要选择gc.log 的路径将需要手动删除尾随点。

这样的用户也可能需要调整路径,例如里面有空格,但这应该解决这种非常常见的情况。

【讨论】:

以上是关于在 git svn clone/fetch 期间避免“警告:有太多无法访问的松散对象”的主要内容,如果未能解决你的问题,请参考以下文章

Git Svn dcommit 错误 - 重新启动提交

鹅厂到底是怎么使用 Git 的?

4年前端的爆肝 Git 备忘指南

开眼了,腾讯是如何使用 Git ?

git

在存储库的 SVN 转储期间观察到错误 (Visual SVN)