From SpectLog
Jump to: navigation, search

Problem

I had a Git repository cloned from one of the branches in Subversion, for example:

git svn clone http://example.com/svn/project/branches/experimental

Over the course of making changes to Subversion, there was a revision, for example, r100 which contain lots of mistakenly modified files. As usual, this revision was incorporated into Git history:

git svn rebase

At this point the content of Git repository could be drawn like this:

-r99---r100           remotes/git-svn
         \
          A---B       master

The problem was that r100 had to be reverted in Subversion. And the revert procedure removed experimental branch/directory altogether and copied the old content of this branch/directory from revision r99 (effectively replacing overwriting changes made in r100 by previous content from r99) in two revisions r101 and r102:

svn co http://example.com/svn/project/branches/
svn rm experimental
svn ci # r101: removing

svn cp -r99 http://example.com/svn/project/branches/experimental@99 .
svn ci # r102: copying

Now Git repository could fetch the changes from Subversion:

git svn fetch

At this point the content of Git repository could be drawn like this:

   r102               remotes/git-svn
  /
-r99---r100
        \
         A---B        master

Trying to rebase current work in master using git-svn will not work:

git svn rebase
Unable to determine upstream SVN information from history

The reason apparently is that current master was previouly rebased on top of r100 which is not common ancestor to the revisions in Subversion.

Solution

Since git-svn maintains liner history, in order to let git-svn continue all changes in master should be rebased on top of r102 instead of r100 (note that rebase is sub-command of git, not git svn):

git rebase --onto remotes/git-svn fe3e42 master

This command takes 3 commits in parameters (git rebase --onto BASE A B):

BASE = new base (remotes/git-svn)
A    = start commit (fe3e42/git-svn)
B    = final commit (master/git-svn)

Any subsequent rebase to get updates from Subverion will work.

References

There are a number of other reasons to have the same error. In some cases it is due to Subversion URL changes or even more complex scenarios: