git树包含重复的文件条目

在20次提交后，我遇到了一些行尾问题，发生了一些奇怪的事情。现在git fsck显示：

Checking object directories 100% (256/256), done.
error in tree ee2060e71cb36d33be5ddc1fe9ca8d7dd0ab35cd: contains duplicate file entries
Checking objects: 100% (8633/8633), done.

git show ee2060展示了：

File1.cs
File2.cs
File2.cs
File2.cs
File3.cs

这使我无法使用遥控器。git推送显示：

error: unpack failed: index-pack abnormal exit
To https://github.com/username/Project.git
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'https://github.com/username/Project.git'

---

我试过重新包装和收集垃圾。如何解决此问题？

再次重定提交可能会解决此问题。如果这没有帮助，那么您可以使用git低级命令（git cat file）来查看提交中包含这个奇怪的树对象的内容，并在其中重新构建一个没有重复项的树的正确版本。然而，我不知道有任何自动工具能够解决这个问题，而且您可能必须更改所有树并提交已经链接到奇怪树的对象

---

顺便说一句，

git ls tree ee2060

应该向您显示有关受损树中数据的更多详细信息，例如其中引用的文件。

在有问题的提交之前签出新分支。现在从有问题的提交中签出文件。现在使用相同的消息添加和提交它们（使用

-C

选项）。对其余的提交重复此操作。完成后，将另一个分支重置为指向此正确分支。然后您可以推送。

我最终通过执行以下操作修复了回购

从github执行新的克隆，该克隆仅包括问题发生前的提交

将文件系统中混乱的repo添加为新克隆上的远程

辛苦地将提交从坏的repo签出到新克隆的工作副本中

git checkout fe3254FIRSTCOMMITAFTERORIGIN/MASTER/HEAD . // note the dot at the end
// without the dot, you move your head to the commit instead of the commit
// to the working copy, and seems to bring the corrupt object into your good clone

依次提交，从另一个repo手动复制提交消息

从远程删除损坏的回购协议

垃圾收集+修剪

git gc --aggressive --prune=now

当git fsck没有显示重复的文件条目时，请高兴地哭泣

---

过去我使用GitReplace和GitMktree来解决这个问题。基本上保留断开的树对象，但覆盖所有链接并使它们指向新对象

首先我们抓取坏树：

git ls tree bad\u tree\u hash>tmpfile.txt

这写下了你的坏树。例如：

040000·tree·3cdcc756ee0ed636c44828927126911d0ab28a18 →  xNotAlphabetic
040000·tree·4ad0d8ef014b8cc09c95694399254eff43217bfb →  EXT
040000·tree·d65085e4a05ea9ac8b79e37b87202dd64d402c2e →  duplicateFolder
040000·tree·d65085e4a05ea9ac8b79e37b87202dd64d402c2e →  duplicateFolder
040000·tree·fd0661d698ace91135a8473b26707892b7c89c32 →  ToolTester
040000·tree·d65085e4a05ea9ac8b79e37b87202dd64d402c2e →  duplicateFolder

NB，·和→是空白[空格]和[制表符]

接下来，编辑文本，删除有问题的行，并使用Unix样式的结尾保存（即仅LF，而不是CRLF）。通过这个例子，我们可以做到：

040000·tree·4ad0d8ef014b8cc09c95694399254eff43217bfb →  EXT
040000·tree·d65085e4a05ea9ac8b79e37b87202dd64d402c2e →  duplicateFolder
040000·tree·fd0661d698ace91135a8473b26707892b7c89c32 →  ToolTester
040000·tree·3cdcc756ee0ed636c44828927126911d0ab28a18 →  xNotAlphabetic

键入

cat tmpfile.txt | git mktree

，它将创建一个新的固定树对象并保存它，然后返回新的哈希：

a55115e4a05ea9ac8b79e37b872024d64d4r2c2e。用于演示目的
new_tree_hash

下一个git replace将创建一个新的引用，它强制所有以前的事件链接使用新的固定对象。

git replace bad_tree_hash new_tree_hash

这将解决您眼前的问题。如果您感兴趣，请查看

.git/refs/replace

文件夹中的覆盖链接。

---

每当您使用

git fsck

检查存储库时，坏树对象将继续生成警告，但它可以被忽略，并且您的所有提交和其他链接都将保持一致并正常工作

---

---

8年回顾：可能有一种方法可以删除旧的、已损坏的树，因为git replace应该会让它变得毫无意义。

我遇到了这类问题，这里和其他地方的所有解决方案都无法为我解决。最后，我销毁了所有引用坏文件夹名称的提交，这可能是杀伤力过大，但成功地修复了repo

好的，我在问题出现之前签出了，cherry按顺序恢复了提交，跳过了错误的提交，我将master重置为新的分支。然而，git fsck仍然显示重复的条目，即使在尝试了我所能想到的一切来强制剪枝，等等。作为一个健全性检查，我在引入问题之前签出，并在那之后删除所有提交。问题仍然存在。因此，我编写了一个bash脚本来递归地搜索提交树以找到坏树，而它们中的任何一个都没有引用它。有没有办法让git删除我不知道的未引用的对象？只要你没有对错误提交的引用，你就会把它们删除。因为reflog不再缓存引用，所以在对引用进行排序后，只需执行一次git gc--aggressive--prune=now。为什么建议--aggressive？它所做的唯一事情就是忽略以前收集的所有增量信息。更多信息：@riezebosch我不记得为什么我会包含--攻击性的，或者是否需要它来解决问题。好的，我可以想象需要完全重建所有增量来摆脱悬空提交。如果我得到这个重复错误，但能够推拉，我可以忽略这些消息吗？我想是的，因为你永远不会“丢失”任何东西这可能会使未来的指责或其他历史事件变得不可靠。总的来说，复制确实值得警告。这个答案很有希望，但即使在git替换之后，我的新主机（GitHub）也拒绝接受我从旧主机（bitbucket）@Paul获得的推送克隆。最终成功了吗？这对我很有效：bfg——修复文件名重复首选树