如何解决git svn索引不匹配的问题？

当我重新设置git svn的基础时，它在某一点上停下来说：

索引不匹配：树的SHA键！=另一棵树的SHA键。

（我知道这些SHA键对应于一棵树，而不是上述两个SHA键的git提交。）

重读
... 文件列表。。。
致命：坏物体
rev list-1--not:命令返回错误：128

---

我对git的内部工作不是很有经验，所以有没有一系列的步骤来剖析这些问题并可能解决它们呢？

我自己也有这个错误。只需删除ref，如下所示：

rm .git/refs/remotes/git-svn

---

这应该会清除错误。

我已经两次遇到这个错误，两次都是通过删除.git文件夹中的svn文件夹来解决的

rm -r .git/svn

然后使用以下内容重建svn元数据：

git svn fetch

您可能会看到以下信息：

Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
    .git/svn
    (required for this version (1.7.0.4) of git-svn) does not exist.
Done migrating from a git-svn v1 layout

---

之后（重建可能需要一段时间，尤其是在大型存储库上），您应该再次使用svn存储库的工作镜像。

问题在于，在这种情况下，您必须系统地执行此操作：

• 使用git+svn
• 使用git svn在svn上创建分支
• 使用svn工具将分支合并到主干
• 删除svn分支
• 做一个git-svn-rebase

---

有些东西不见了，一切都崩溃了。我知道的唯一恢复方法是删除.git中的所有svn并重建所有内容。这很烦人，需要一段时间

请不要删除.git/svn文件夹来修复此问题。它需要你重建一切，这很烦人，需要一段时间（对于我的回购规模而言，需要几个小时），而且没有必要

我找到了正确的答案，我把它包括在下面

从链接：

在.git目录中运行以下命令：

$ find . -exec grep -Hin 5b32d4ac2e03a566830f30a702523c68dbdf715b {} \;
Binary file ./svn/.caches/lookup_svn_merge.db matches
Binary file ./svn/.caches/check_cherry_pick.db matches

现在从第一个命令的输出中删除匹配的.svn/.cache

$ rm ./svn/.caches/lookup_svn_merge.db
$ rm ./svn/.caches/check_cherry_pick.db

---

现在，

git svn rebase

或

git svn fetch

，让您心满意足。

更新git client并使用以下方法重新提取最后一个svn提交：

git svn reset -r 12345
git svn rebase

---

其中12345是现有的svn修订版。

在我的案例中，问题是由新的/未知的svn作者引起的，该作者不在git svn配置为使用的我的

作者

文件中。它在输出中报告说，我忽略了前几项内容：

Index mismatch: <leftsha1> != <rightsha1>
rereading <anothersha1>
        ... list of files ...
Author: <name> not defined in /path/to/authors file

索引不匹配：！=
重读
... 文件列表。。。
作者：未在/path/to/authors文件中定义

---

因此，这给了我我丢失的名称，以及要添加的文件（我从我的组织用户注册表中提取了这封电子邮件），并且进展顺利。

可能与文件系统的写时拷贝功能（ext4/btrfs/等）有关吧

请参阅：

我遇到了以下错误：

索引不匹配：！=
重读
... 文件列表。。。
在提交（r）中找不到

在SVN repo中查看报告路径的历史记录，我找到了添加文件的SVN修订版。但在Git中查看为该修订版创建的提交时，我发现它不包含任何文件

---

我认为这是由于之前磁盘已满造成的。在对损坏的git提交进行了

git svn重置-r

后，

git svn fetch

再次正常工作。

我在最初的克隆过程中遇到了这个问题，结果发现有人创建了一个名为trunk的分支，它与真实的trunk冲突。忽略/branchs/trunk all worked后，消息中可能同时存在校验和不匹配：

我在这里找到了解决方案：

git svn日志
git svn重置-r-p
git-svn-rebase

我首先想到的是一个可疑的损坏存储库。@Greg Hewgill:谢谢你的建议。我做了一个git fsck，它列出了一堆悬垂的树、提交和blob。我参考了Git用户手册中的这一部分：并试图弄清楚回购协议中发生了什么。幸运的是，几周前我归档了我的.git文件夹，以便我的同事能够启动并运行repo。我用它创建了一个新的回购协议，并继续我的工作，同时我找出了损坏的回购协议发生了什么。我能想到的唯一一件事是，可能有其他人在您之前重新设置了基准，从而更改了远程回购协议的SHA密钥，并给出了您现在看到的错误。如果您要拉取对树所做的更改，修复任何冲突，然后从那里重新设置基础，它可能会正常工作。您只看到挂起的提交，没有丢失的提交？这是相当正常的——当使用git add时，在重定基址时创建悬挂提交，在使用git add时创建悬挂树——索引作为树进行维护。@g19fanatic远程存储库是一个SVN存储库，SVN不支持历史重写，所以我不确定你的意思，我在.git/refs/remotes目录下找不到git svn！？！？！对不起，我弄错了。应该是

.git/refs/remotes/git svn

。我在.git/refs/remotes目录下没有git svn文件！？！？！仔细想想，这看起来毕竟是一个不同的问题。我有同样的“索引不匹配”错误，我通过删除

git svn

remote ref修复了这个错误，但是我没有得到它的其余部分；对于大型存储库来说，这真是太过分了，但在大多数情况下，这可以节省大量的时间。对于我的大型存储库，我只获取了一些最新的提交：“git svn fetch-r 12345:HEAD”。我仍然可以看到以前的提交。肯定是杀伤力过大，完全没有必要。这至少应该有一个警告。添加

--log window size=5000

（或更大）将大大加快提取速度。是的，我后来发现了这种技术。在下一次尝试中，我刚刚清除了

缓存

，这比删除

.git/svn

要快得多。忘了更新这里。感谢您发布您的答案。同时，我在邮件中也遇到了校验和不匹配的问题，此解决方案无法解决这种情况下的问题。这在摆弄

。缓存

目录无法解决的情况下起作用。

Index mismatch: <leftsha1> != <rightsha1>
rereading <anothersha1>
        ... list of files ...
Author: <name> not defined in /path/to/authors file

git svn log <item with checksum mismatch>
git svn reset -r<top history revision in the log> -p
git svn rebase