git svn rebase: Incomplete data: Delta source ended unexpectedly

Question

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 ra

Answer 1

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.

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

Answer 3

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.

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

Answer 5

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.