我一直在维护the git mirror the watir project。几周前的某个时候，我们有人准备提交他们的第一个基于git的补丁。不幸的是，由于项目的多平台特性，我们遇到了关于线路结束（CRLF与LF等）的一些问题。
我尽我所能设置the autocrlf option（到'输入'），然后做一些 - 硬重置。但是，几天之后，每日更新（git svn rebase）就会出现这个错误：
Incomplete data: Delta source ended unexpectedly
我已经尝试使用谷歌搜索该怎么做，但即使删除.git / config中的autocrlf设置也无济于事。我担心工作副本是腐败的，但我希望它不是不可恢复的。
显然，一个可能的行动方案是从svn重新导入并开始一个新镜像，但我希望我们不必这样做，因为当前的镜像已经分叉了，人们有在他们的分叉中开发了新代码。
提前感谢您的帮助。
答案 0 :(得分：16)
我在尝试从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工作了。
答案 1 :(得分：5)
根据个人经验，当从具有相同参数的svn存储库进行克隆或获取时，git-svn始终生成完全相同的提交（尝试：创建虚拟存储库，使用git-svn克隆它，执行更多提交，克隆再次，并获取第一个副本;结果提交应该具有完全相同的哈希）。
这给你一个有趣的选择：你可以用相同的参数开始一个单独的新镜像，并比较两者以查看它们的分歧（或者它们根本不同;确保比较哈希，因为它们是重要的）。如果它们是相同的（或者你决定它们发散后的提交无关紧要），你可以使用新镜像而不破坏分支（如果你决定忽略一些不同的提交，则可以减少它们的数量）。
答案 2 :(得分：4)
我遇到git svn fetch同样的问题，但重置方法对我不起作用，也许是因为我真的不知道腐败何时发生。这是最终对我有用的东西。我做了一个没有错误的git svn fetch --ignore-paths="/branches/"。在那之后，我又一次做了我的git svn fetch，这一次有效。
答案 3 :(得分：0)
我遇到了同样的问题，就像托德的情况一样，前一次修订解决了这个问题。
我认为解决方案是转到问题文件的前一版本的两个步骤。
答案 4 :(得分：0)
我见过类似的问题。当我对svn repo进行部分克隆时会发生这种情况。我猜git-svn在进行dcommit时无法找到文件的原始来源。我通过确保我完全更新（git svn rebase）然后使用git svn set-tree来提交对subversion的特定更改来修复它。如果您要进行大量更改，这可能会很麻烦，因为您需要按顺序手动提交每个更改，但如果您只有一个或两个提交要推送它就会很好。