我一直在维护 git 镜像。 org/" rel="noreferrer">watir 项目。 几周前的某个时候，我们有人准备提交他们的第一个基于 git 的补丁。 不幸的是，由于该项目的多平台性质，我们遇到了一些有关行结尾的问题（CRLF 与 LF 等）。
我尝试了设置 autocrlf 选项 （“输入”），并做了一些 - - 硬重置。 然而，几天后，每日更新（git svn rebase）抛出了这个错误：
Incomplete data: Delta source ended unexpectedly
我尝试在谷歌上搜索该怎么做，但即使删除 .git/config 中的 autocrlf 设置也没有帮助。 我担心工作副本已损坏，但我希望它不是不可恢复的。
显然，一个可能的做法是从 svn 重新导入并启动一个新的镜像，但我希望我们不必这样做，因为当前的 watir-mirror 已经分叉了，并且人们已经开发了新代码在他们的叉子里。
预先感谢您的任何帮助。
I have been maintaining the git mirror of 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.
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:
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.
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.
Thanks in advance for any help.
发布评论
评论（5）
我在尝试从 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 工作了。
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.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 thegit svn reset -r XXXXXworked.从个人经验来看，当使用相同的参数从 svn 存储库克隆或获取时，git-svn 总是生成完全相同的提交（尝试一下：创建一个虚拟存储库，使用 git-svn 克隆它，再做一些提交，再次克隆它，并获取第一个副本；生成的提交应该具有完全相同的哈希值）。
这为您提供了一个有趣的选择：您可以使用相同的参数启动一个单独的新镜像，并比较两者以查看它们在哪里存在分歧（或者它们根本存在分歧；请务必比较哈希值，因为它们才是重要的）。 如果它们是相同的（或者您决定分歧后的提交无关紧要），您可以使用新的镜像而不破坏分叉（或者破坏更少的分叉，如果您决定忽略一些分歧的提交）。
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).
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).
我在使用 git svn fetch 时遇到了同样的问题，但重置方法对我不起作用，也许是因为我真的不知道损坏何时发生。 这最终对我有用。 我做了一个 git svn fetch --ignore-paths="/branches/" ，运行没有错误。 之后，我再次执行了 git svn fetch ，这次成功了。
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 agit svn fetch --ignore-paths="/branches/"which ran without error. After that, I once again did mygit svn fetch, and this time worked.我遇到了同样的问题，就像托德的情况一样，转到以前的版本解决了这个问题。
我认为解决方案是对有问题的文件进行两步修改。
i had the same problem and like Todd's case, going to a previous revision fixed the problem.
I think the solution is to go to two steps previous revision of the problematic file.
我见过类似的问题。 当我对 svn 存储库进行部分克隆时，就会发生这种情况。 我猜 git-svn 在执行 dcommit 时找不到文件的原始来源。 我通过确保我完全是最新的（git svn rebase）然后使用 git svn set-tree 提交对 subversion 的特定更改来修复它。 如果您有很多更改需要提交，这可能会很痛苦，因为您需要按顺序手动提交每个更改，但如果您只有一两个提交需要推送，则效果很好。
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.