git svn rebase：数据不完整：增量源意外结束答案

【问题标题】：git svn rebase: Incomplete data: Delta source ended unexpectedlygit svn rebase：数据不完整：增量源意外结束
【发布时间】：2008-10-17 03:47:52
【问题描述】：

我一直在维护the git mirror 的the watir project。几周前的某个时候，我们有人准备提交他们的第一个基于 git 的补丁。不幸的是，由于项目的多平台性质，我们遇到了一些关于行尾（CRLF 与 LF 等）的问题。

我尝试了设置the autocrlf option（设置为“输入”），并进行了一些 --hard 重置。然而，几天后，每日更新（git svn rebase）正在喷出这个错误：

Incomplete data: Delta source ended unexpectedly

我试过用谷歌搜索做什么，但即使删除 .git/config 中的 autocrlf 设置也无济于事。我担心工作副本已损坏，但我希望它不是不可恢复的。

显然，一个可能的做法是从 svn 重新导入并启动一个新镜像，但我希望我们不必这样做，因为当前的 watir-mirror 已经被分叉了，人们已经在他们的分支中开发了新代码。

提前感谢您的帮助。

【问题讨论】：

您对这个问题有进一步了解吗？我们目前似乎有同样的问题。（上次 git-svn 结帐花了 3 天时间，所以我希望我能避免这种情况）
@pvgoddijn 不，抱歉，从未真正找到解决方案。问题就这样消失了，因为他们正式搬到了 github 并放弃了 svn。

标签： svn git version-control corrupt

【解决方案1】：

我在尝试从 brlcad svn 存储库创建 git 存储库时遇到了同样的问题。我通过git svn reset --r XXXXX 解决了这个问题，我将 XXXXX 设置为在最初产生错误之前大约 50 个修订版。

退回单个修订版未能成功解决错误。作为该过程的一部分，我从 git 收到关于 HEAD 未定义的错误。为了解决这个问题，我做了一个git svn find-rev XXXXX 来确定与我想要的修订相对应的哈希，然后 git checkout。在此之后，关于 HEAD 的错误消失了，git svn reset -r XXXXX 工作了。

【讨论】：

非常感谢。这有助于解决类似的问题。我只是将修订号设置为当前修订之前的一个修订。
这有帮助，但就在我杀死所有僵尸 git/perl 进程并删除 index.lock 文件之后。在这里查看我的答案：stackoverflow.com/questions/21334923/…

【解决方案2】：

根据个人经验，git-svn 在克隆或从具有相同参数的 svn 存储库中获取时总是生成完全相同的提交（尝试：创建一个虚拟存储库，使用 git-svn 克隆它，执行更多提交，克隆再次，并在第一个副本上获取；生成的提交应该具有完全相同的哈希）。

这为您提供了一个有趣的选择：您可以使用相同的参数启动一个单独的新镜像，并比较两者以查看它们在哪里分歧（或者它们根本分歧；一定要比较哈希值，因为它们才是最重要的）。如果它们是相同的（或者您在它们分歧后决定提交无关紧要），您可以使用新镜像而不破坏分叉（或者如果您决定忽略一些分歧的提交，则破坏更少的分叉）。

【讨论】：

哈希值保持不变，对吧？好吧，我应该知道/记得 git 散列提交增量的实际字节。不幸的是，由于我想第二次克服 CRLF LF 问题，我可能会遇到分歧。不过，我会尝试重新导入。谢谢！
好的，CesarB，我尝试通过执行 git svn init，将 autocrlf 设置为输入，然后 git svn fetch 从 svn 源重新导入——但我得到了同样的错误（“delta source. ..") 在提取的中间。还有其他建议吗？
尽量不玩autocrlf，就像你最初的镜子一样。如果它一直有这个错误，我怀疑是 svn 或 git-svn 坏了。
好吧，没有 crlf 设置，一切正常，但合并对行尾差异感到恐慌，并显示出巨大的差异，即使唯一的增量与空白有关。我也尝试了 whitespace = cr-at-eol，但这在这方面似乎没有帮助。
无论如何，这可能是一个废弃的问题，因为据报道 watir 项目将在年底前完全迁移到 git。尽管如此，还是感谢您的意见。

【解决方案3】：

我在git svn fetch 上遇到了同样的问题，但重置方法对我不起作用，也许是因为我真的不知道损坏发生的时间。这就是最终对我有用的方法。我做了一个git svn fetch --ignore-paths="/branches/"，它运行没有错误。在那之后，我再次做了我的git svn fetch，这次成功了。

【讨论】：

重置方法对我也不起作用。但我不想忽略分支。我该怎么办？
@anony 您只是忽略第一个命令的分支，然后当您第二次运行时，您不会忽略分支，它会选择更改。
嗨，唐，这对我不起作用。以下是我得到的错误：数据不完整：Delta 源意外结束于 /usr/lib/perl5/site_perl/Git/SVN/Ra。下午282行
@anony - 好的，这只是意味着您忽略的部分（即 /branches/）不够广泛。您的 svn 存储库中有损坏，但显然不在 /branches 下。您可能必须依靠反复试验才能找到它的位置。

【解决方案4】：

我遇到了同样的问题，并且像 Todd 的情况一样，去上一个版本解决了这个问题。

我认为解决方案是对有问题的文件进行两步修改。

【讨论】：

如何识别有问题的文件？

【解决方案5】：

我见过类似的问题。它发生在我对 svn repo 进行部分克隆时。我猜 git-svn 在执行 dcommit 时找不到文件的原始来源。我已经通过确保我完全是最新的（git svn rebase）然后使用 git svn set-tree 来提交对 subversion 的特定更改来修复它。如果您有很多更改要提交，这可能会很痛苦，因为您需要按顺序手动提交每个更改，但如果您只有一两个提交要推送，则效果很好。

【讨论】：