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