git svn rebase: Incomplete data: Delta source ende

问题:

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.

回答1:

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 XXXXX to 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 XXXXX worked.

回答2:

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).

回答3:

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.

回答4:

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.

回答5:

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.