git树（仍然）包含重复项和错误信号13_Git_Github

git树（仍然）包含重复项和错误信号13

git github

git树（仍然）包含重复项和错误信号13,git,github,Git,Github,我有一个git存储库，它是这样构造的 $ git init 在多次添加、提交和猛烈的键盘敲击之后，我准备将其推送到我的GitHub repo $ git remote add origin git@github.com:me/Foo.git $ git push -u origin master Counting objects: 456, done. Delta compression using up to 8 threads. Compressing objects: 100% (125

我有一个git存储库，它是这样构造的

$ git init

在多次添加、提交和猛烈的键盘敲击之后，我准备将其推送到我的GitHub repo

$ git remote add origin git@github.com:me/Foo.git
$ git push -u origin master
Counting objects: 456, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (125/125), done.
remote: error: object c9edb23c0e6c48772785b2a7d89d08c0807b2d4a:contains duplicate file     entries
remote: fatal: Error in object
error: pack-objects died of signal 13
error: failed to push some refs to 'git@github.com:me/Foo.git'

因此，我找到了这篇文章，并按照那里的说明进行了搜索

$ git ls-tree c9edb > bad_tree.txt

删除重复条目（只有1个！）

好的，文章说fsck仍然会显示坏树，但是push现在应该可以工作了。让我们修一下13号信号机。SO的文章说这是一个文件大小的问题。好的，让我们看看这个

$ git count-objects -v
count: 0
size: 0
in-pack: 457
packs: 1
size-pack: 1910
prune-packable: 0
garbage: 0
size-garbage: 0

嗯，真奇怪。它说只有1.9MB。让我们再检查一下

$ du -h .git
8.0K    .git/logs/refs/heads
12K     .git/logs/refs
24K     .git/logs
1.9M    .git/objects/pack
8.0K    .git/objects/info
1.9M    .git/objects
44K     .git/hooks
4.0K    .git/branches
12K     .git/info
4.0K    .git/refs/heads
4.0K    .git/refs/tags
4.0K    .git/refs/replace
16K     .git/refs
2.1M    .git

好吧，有点疯狂。Git和文件系统一致认为整个存储库只有~2MB，但我得到的是推送信号-13。嗯，让我们再试一次

$ git push -u origin master
Counting objects: 456, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (125/125), done.
remote: error: object c9edb23c0e6c48772785b2a7d89d08c0807b2d4a:contains duplicate file     entries
remote: fatal: Error in object
fatal: The remote end hung up unexpectedly
error: pack-objects died of signal 13
error: failed to push some refs to 'git@github.com:me/Foo.git'

Grr。“来自地狱的内容管理者”，的确如此。我的回购协议刚刚破产了吗？是否有可能在没有历史记录的情况下，只推送最后一次对github的承诺？（最好不要让我的本地回购协议成为另一个本地回购协议的远程协议，也不要复制整个协议）。

我碰巧在阅读O'Reilly时发现了一个巧妙的小技巧，使用

git branch filter

。我应该注意到，

duplicate entry

错误是由于在一次提交中将一个子文件夹作为目录和符号链接添加到索引中（我不会再这样做了！）

尽管我们刚刚从orbit中删除了该子目录，但坏blob仍然在repo中

$ git fsck
Checking object directories: 100% (256/256), done.
error in tree c9edb23c0e6c48772785b2a7d89d08c0807b2d4a: contains duplicate file entries
Checking objects: 100% (457/457), done.

$ cd ~/Foo_new
$ git clone --no-hardlinks file://~/Foo

看起来git不想放弃那一团！这很容易解决。通过复制回购协议，可以（最安全地）解决悬而未决的问题

$ git fsck
Checking object directories: 100% (256/256), done.
error in tree c9edb23c0e6c48772785b2a7d89d08c0807b2d4a: contains duplicate file entries
Checking objects: 100% (457/457), done.

$ cd ~/Foo_new
$ git clone --no-hardlinks file://~/Foo

--no hardlinks

选项防止git使用硬链接优化克隆，并确保克隆的repo包含旧repo中所有内容的副本，以便您可以安全地删除旧repo。快速检查显示现在一切正常

$ git fsck --full
Checking object directories: 100% (256/256), done.
Checking objects: 100% (433/433), done.

现在我需要重置我的遥控器，因为这是一个克隆的repo

$ git remote set-url origin git@github.com:me/Foo.git

然后推到github

$ git push origin master
Counting objects: 433, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (115/115), done.
Writing objects: 100% (433/433), 471.04 KiB | 0 bytes/s, done.
Total 433 (delta 318), reused 433 (delta 318)
To git@github.com:me/Foo.git
 * [new branch]      master -> master

成功

我今天也遇到了同样的问题，在尝试了上述许多内容后，我最终不再“关心”历史本身，而是决定将历史压缩成一个承诺

例如手头的情况：

分支主节点断开；
- 尝试推送时出现错误13
- 这发生在10-15分钟左右
分支源站/主站无法接收新更新

然后，我执行了以下简单步骤：

git签出主机
git分行主管维护旧历史记录
git重置原点/主控点--软
git commit-a-m“一次压缩提交…”
git推送-u源主机-f

当尝试执行交互式重基时，此操作失败，因为它仍在尝试“重用”现有的“已断开”提交以进行重播，从而导致问题再次发生。这种简单地抛弃所有被破坏的历史并进行一次提交的解决方案最终对我来说是最干净的

干杯，

Rob

因此，从技术上讲，我不应该说这样的话，因为这并没有真正增加问题本身，而是首先感谢你出色地完成了自己的研究，并对你已经尝试过的内容进行了详细解释。我在链接文章中找不到你可以推动糟糕历史的地方，还有人说它对包传输不起作用（包是

包对象

的输出）。@jthill，你说得对。我在文档页面上没有看到。看起来filter branch（无论是在代码中还是在文档中）也有一个bug，因为文档说filter branch将使所有ref替换永久化，但事实并非如此。@Cupcake，谢谢！我只是想让它可读性强，并且能很快理解。@Tim你知道你可以回答自己的问题，对吗？