git svn fetch gives "Invalid revision range" "error: 128" after bfg cleanup

Question

I have a Git repo in migration from SVN with git-svn. I used git svn fetch to get the latest commits from SVN. I wanted to push the repo to GitHub, but there were some files in the history larger than 100 MB that I had to remove, so I used bfg repo cleaner to get rid of them.

$ java -jar bfg-1.12.14.jar --strip-blobs-bigger-than 100M
...
In total, 10235 object ids were changed. Full details are logged here:
...
BFG run is complete! When ready, run: git reflog expire --expire=now --all && git gc --prune=now --aggressive
...
$ git reflog expire --expire=now --all && git gc --prune=now --aggressive
Counting objects: 204963, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (171827/171827), done.
Writing objects: 100% (204963/204963), done.
Total 204963 (delta 91547), reused 106805 (delta 0)

$ git svn fetch -A authors-transform.txt
fatal: Invalid revision range b156a7b66be002c3bf38987ea503f5c852146343 
rev-list --pretty=raw --reverse b156a7b66be002c3bf38987ea503f5c852146343..refs/remotes/git-svn --: command returned error: 128

How can I make it work without reinitialising the whole repository, as I don't want those files again in the history (they exceed GitHub's limit)? Any way to recalculate the hash or to make it ignore the mismatch?

Answer 1

Whilst git-svn provides pretty decent mirroring support of Subversion to Git, you won't be able to combine that with a history-rewriting clean-up tool such as BFG.

If you need to clean-up the repository, you should think about completing your Subversion-to-Git migration, scripting your conversion and migration, and moving to Git-first commits and abandoning the Subversion repository alogether, at which point you won't care about git-svn anymore. You will find it very difficult to scrub the Subversion history, and it will be impossible to relate a scrubbed Subversion and a BFG-scrubbed Git with each-other. As you have already observed, git-svn is not going to tolerate the rewrite.

Plan for your BFG clean-up to be a once-off exercise, scripted and tested against your ongoing git-svn fetches, but once run, stop using Subversion altogether and only use Git.

Answer 2

After doing something similar to you (cloning an svn repo with git svn clone --prefix=svn/ ...) and then running

> bfg --strip-blobs-bigger-than 20M
> git reflog expire --expire=now --all && git gc --prune=now --aggressive

to remove large files from my repo, I found I also could not update from the svn repo with either a git svn fetch or a git svn rebase. At first I had errors related to revision range, then I had errors related to missing or invalid objects. To fix this, I had to remove the .revmap.* file, as well as the index on both the local and remote branches, then regenerate them. The complete set of commands that fixed the problem for me were:

> git fsck --full
> git prune
> rm .git/svn/refs/remotes/svn/trunk/.rev_map.*
> rm .git/index
> rm .git/svn/refs/remotes/svn/trunk/index
> git svn rebase

I have no idea what kind of dragons I unleashed for the future, but my repo seems to work now. I can successfully pull new svn updates to my git repo, and merge them into other branches locally.

Note that I do not push back up to svn through git, so I don't know if that will cause issues. Instead, I keep an "svn" branch that contains a pure copy pulled from the svn repo, and I work locally in git on branch "master". I then push changes back up using command-line svn from "master", pull them back to my "svn" branch, then merge them back into "master".