7

我遇到了关于我的包文件的多个错误，这些错误看起来非常隐蔽，这是一个非常可怕的交易，因为这是一个实时站点并且不知道如何处理它，也许有人可以通过它告诉我，这是发生了什么。

看来我有一个丢失的对象，而且我的包文件的计数也不好？

remote: Counting objects: 25733, done.
remote: Compressing objects: 100% (12458/12458), done.
remote: Total 19185 (delta 6914), reused 17995 (delta 6535)

Receiving objects: 100% (19185/19185), 1.69 GiB | 465 KiB/s, done.
Resolving deltas: 100% (6914/6914), completed with 1058 local objects.

error: packfile .git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack claims to have 19185 objects while index indicates 20243 objects
error: packfile .git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack cannot be accessed
error: packfile .git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack claims to have 19185 objects while index indicates 20243 objects
error: packfile .git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack cannot be accessed
error: packfile .git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack claims to have 19185 objects while index indicates 20243 objects
error: packfile .git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack cannot be accessed

error: unable to find e17196d88ae91dea07b4d61716b91dac581fb131

error: packfile .git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack claims to have 19185 objects while index indicates 20243 objects
error: packfile .git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack cannot be accessed

fatal: object e17196d88ae91dea07b4d61716b91dac581fb131 not found

编辑 另一个似乎已经发芽了，所以现在我有....

.git/objects/pack/pack-1f0643b00b9c201338b7f1365ef188ef682a6a9e.pack 
.git/objects/pack/pack-931e28ca404e28040a10085dd1534ef12cf18c6d.pack

我已经尝试将它们复制到 www-root 并删除它们，现在正在运行git-gc并尝试使用git fetch origin

git-gc现在返回

bad sha1 file: .git/objects/05/.a2e1939ce5a53d5ec7c3cacc4df97acd09c6af.hdgIVe
bad sha1 file: .git/objects/80/.1a75684e9d869e9ed7c1ded674c55caa17c524.YUr1Yu
bad sha1 file: .git/objects/8c/.7e8381b3e0d0a1f1d4fa328f0dda0a1dbd814a.L0255H
bad sha1 file: .git/objects/c5/.32926ac2d67785cb8580b885ac3d3fd7075f57.rDsW4H
Removing stale temporary file .git/objects/pack/tmp_pack_jnP5qn
4

2 回答 2

3

如“损坏的 git repo 的问题”及其相关讨论中所述：

然后将其中许多对象打包到一个包文件中以节省空间。你通过改变它们的内容破坏了这些包文件——更糟糕的是：改变它们的内容的长度。
git fsck实际上并没有修复关于 git 存储库的任何内容，它只是检查错误并报告它们。
git unpack-objects另一方面，能够从损坏的包文件中尽可能多地解包，但您的 repo 中仍然会出现错误，正如git fsck --full将报告的那样。
请参阅“如何修复损坏的存储库？ ”或“如何从存储库中删除所有损坏的引用？ ”。

请注意，对于 Git 2.4.3（2015 年 6 月），不再有警告packfile .git/objects/pack/pack-xxx.pack cannot be accessed。
这允许只关注实际错误。

请参阅Jeff King ( )的提交 319b678 [2015 年 3 月 31 日] 。（由Junio C Hamano 合并 -- --在提交 3c91e99中，2015 年 6 月 5 日）peff
gitster

和 Peff 一样，这个解释很有启发性：

sha1_file: 静噪 " packfile cannot be accessed" 警告

当我们在包文件索引中找到一个对象时，我们确保我们仍然可以打开包文件本身（或者它已经打开），因为它可能已被同时重新打包删除。
如果我们无法访问包文件，我们会为用户打印一个警告并告诉调用者我们没有该对象（然后我们可以在放弃之前查看其他包文件，或者找到一个松散的版本）。

我们打印给用户的警告并没有真正完成任何事情，它可能会让用户感到困惑。

在正常情况下，它是完全噪声；我们在其他地方找到了对象，用户不必关心我们看到了一个过时的包文件索引。完全不影响操作。

一个可能更有趣的情况是我们后来找不到对象，并向用户报告失败。在这种情况下，警告可以被认为是最终失败的线索。但这在实践中并不是一个真正有用的线索。我们甚至不会一致地打印它（因为我们正在与另一个进程竞争，我们甚至可能看不到.idx文件，或者我们可能赢得比赛并打开包文件，完成操作）。

此补丁完全删除警告（不仅来自fill_pack_entry站点，还来自相同的使用pack-objects）。
如果我们确实发现错误情况下的警告很有趣，我们可以把它塞进去并在稍后die()由于对象损坏时将其显示给用户。但这种复杂性是不值得的。

在 Git 2.22.1（2019 年第三季度）中，“ git update-server-info”过去常常在其输出中留下陈旧的包文件，这已得到纠正。

请参阅Eric Wong ( ) 的commit e941c48（2019 年 5 月 23 日）。 帮助者：Jeff King ( )。（由Junio C Hamano 合并 -- --在提交 776d668中，2019 年 7 月 25 日）ele828
peff
gitster

server-info：不列出未链接的包

包含不存在的包objects/info/packs会导致愚蠢的 HTTP 客户端中止。

v2ALLOC_GROW：按照 Jeff King 的建议使用单循环

在 Git 2.35（2022 年第一季度）中，tmp-objdir API 有了新接口，以帮助在核心内使用隔离功能。

请参阅Neeraj Singh ( ) 的提交 ecd81df和提交 b3cecf4（2021 年 12 月 6 日）。（由Junio C Hamano 合并——在提交 0dc90d9中，2022 年 1 月 3 日）neerajsi-msft
gitster

tmp-objdir：用于创建临时可写数据库的新 API

基于补丁程序：Elijah Newren
签署人：Neeraj Singh
审核人：Elijah Newren

tmp_objdirAPI 提供了创建临时对象目录的能力，但其设计目标是让子进程访问这些对象存储，然后主进程将对象从它迁移到主对象存储或只是删除它。
子进程会将其视为其主要数据存储并对其进行写入。

在这里，我们添加了tmp_objdir_replace_primary_odb将当前进程的可写“主”对象目录替换为指定目录的功能。
以前的主对象目录在tmp_objdir_migrate或中恢复tmp_objdir_destroy。

对于用例，在 object_database`` 中--remerge-diff添加一个新will_destroy标志struct 来标记不需要 fsync 持久性的临时对象数据库。

添加 ' git prune' ( man )支持以删除临时对象数据库，并确保它们的名称以tmp_特定于操作的名称开头并包含。

修剪消息来自：

Removing stale temporary file ...

到：

Removing stale temporary directory ...
于 2015-06-08T21:26:55.387 回答
1

看起来另一个回购中有一些腐败。如果它是中央仓库，请从您的仓库中重新克隆它，然后让每个人都推送他们的分支。在那之后你的拉动应该起作用 - 除非你无法传达你正在向所有人修复回购的消息。

于 2012-07-09T19:17:56.520 回答