git svn rebase：数据不完整：Delta 源意外结束

git svn rebase: Incomplete data: Delta source ended unexpectedly

提问by Pistos

I have been maintaining the git mirrorof the watir project. Some time a couple weeks ago, we had someone ready to submit their first git-based patch. Unfortunately, we ran into some issues regarding line endings (CRLF vs. LF, etc.) because of the multi-platform nature of the project.

我一直保持混帐镜的该项目的Watir。几周前的某个时候，我们有人准备提交他们的第一个基于 git 的补丁。不幸的是，由于项目的多平台性质，我们遇到了一些关于行尾的问题（CRLF 与 LF 等）。

I tried what I could to set the autocrlf option(to 'input'), and do some --hard resets. However, a few days later, the daily update (git svn rebase) is spewing this error:

我尽我所能设置autocrlf 选项（到“输入”），并进行一些 --hard 重置。然而，几天后，每日更新 (git svn rebase) 出现了这个错误：

Incomplete data: Delta source ended unexpectedly

I've tried googling around for what to do, but even removing the autocrlf setting in the .git/config hasn't helped. I fear the working copy is corrupt, but I hope it is not unrecoverable.

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

Obviously, a possible course of action is to just re-import from svn and start a fresh mirror, but I hope we don't have to do that, since the current watir-mirror has already been forked, and people have developed new code in their forks.

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

Thanks in advance for any help.

在此先感谢您的帮助。

回答by Todd Wagner

I had this same problem in trying to create a git repository from the brlcad svn repository. I solved it by doing git svn reset --r XXXXX, where I set XXXXX to be about 50 revisions prior to the one that originally produced the error.

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

Stepping back a single revision was not successful in resolving the error. As part of the process, I received errors from git about HEAD not being defined. To resolve this, I did a git svn find-rev XXXXXto determine the hash corresponding to the revision I wanted, then git checkout. After this, the errors about HEAD were gone and the git svn reset -r XXXXXworked.

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

回答by CesarB

From personal experience, git-svn always generates the exact same commits when cloning or fetching from a svn repository with the same parameters (try it: create a dummy repository, clone it with git-svn, do some more commits, clone it again, and fetch on the first copy; the resulting commits should have the exact same hash).

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

This gives you an interesting option: you can start a separate fresh mirror with the same parameters, and compare both to see where they diverge (or it they diverge at all; be sure to compare the hashes, since they are what matters). If they are the same (or you decide the commits after they diverge don't matter), you can use the fresh mirror without breaking the forks (or breaking less of them, if you decided to ignore a few diverging commits).

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

回答by Don Branson

I had the same problem with git svn fetch, but the reset approach didn't work for me, perhaps because I don't really know when the corruption occurred. Here's what finally worked for me. I did a git svn fetch --ignore-paths="/branches/"which ran without error. After that, I once again did my git svn fetch, and this time worked.

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

回答by yigit

i had the same problem and like Todd's case, going to a previous revision fixed the problem.

我遇到了同样的问题，就像 Todd 的情况一样，转到以前的修订版解决了该问题。

I think the solution is to go to two steps previous revision of the problematic file.

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

回答by Trevor

I've seen a similar problem. It occurs when I do a partial clone of an svn repo. I'm guess git-svn can't find the original source of the file when doing a dcommit. I've fixed it by ensuring I'm completely up to date (git svn rebase) then using git svn set-tree to commit specific changes to subversion. If you have a lot of changes to commit, this can be a pain since you need to manually commit each change in order but it works well if you only have one or two commits to push.

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