Rebase fails when subversion library has a number in its branches/ directory

[jsdalton]

At least that was my diagnosis when I looked at this briefly. It seems like git is getting confused by the ambiguity of "1.4".

$ svn2git --rebase --verbose
Running command: git status --porcelain --untracked-files=no
Running command: git branch -l --no-color
* (no branch)
  1.4
  6.3.2
  master
Running command: git branch -r --no-color
  origin/master
  svn/1.4
  svn/6.3.2
  svn/tags/6.3.4
  svn/tags/6.4
  svn/trunk
Running command: git svn fetch
Running command: git checkout -f "1.4"
warning: refname '1.4' is ambiguous.
Switched to branch '1.4'
Running command: git rebase "remotes/svn/1.4"
warning: refname '1.4' is ambiguous.
First, rewinding head to replay your work on top of it...
error: Ref refs/heads/1.4 is at 945bb2b34ec0a6bba7ae71bb91684005c44470a1 but expected a487bb4a0fccd87a1ecbd0d05720da97391037d0
fatal: Cannot lock the ref 'refs/heads/1.4'.
Could not move back to refs/heads/1.4
command failed:
2>&1 git rebase "remotes/svn/1.4"

This is for a github mirror I have for a Wordpress plugin in the Wordpress SVN repository. This is the repository directory that's giving me difficulty: http://plugins.svn.wordpress.org/google-analyticator/

[markwu]

@jsdalton I have the same problem. Do you find any way to work around?

[jsdalton]

@markwu See the pull request I just submitted. I patched up my local copy of svn2git with that change and now when I run:

$ svn2git --rebase --nobranches

It skips the branch checking stuff that was throwing the error. The rest of the repository rebases as expected.

[derektamsen]

I am also having the same issue. However, I think I see what the issue is. In both @jsdalton example and my svn repo I have a branch and a tag with the same name. It appears that git does not like that senario and thinks the tag's revision should be the branch's or vise versa.

In @jsdalton example the wordpress plugin's svn repo has both a branch named 1.4 and a tag named 1.4.

I think the correct solution is to move either the tag or the branch to a new name. The only issue with that is if you are importing the complete history (or the history including when the bad tag/branch existed) svn2git still needs to create the original branch/tag then move it later.

In theory I am thinking the way to fix it correctly is to svn move the branch back on the revision it was created so basically the bad tag/branch is never created. Although, I am not really sure how to do that at the moment. Back dating a change is beyond my knowledge. Going to keep googling to see if I can find a good solution though.

[derektamsen]

I finally have a solution that works. Using the google-analyticator as an example:

1. Move the branch with a conflicting name on the source svn repo:
   svn mv http://plugins.svn.wordpress.org/google-analyticator/branches/1.4 http://plugins.svn.wordpress.org/google-analyticator/branches/1.4_branch
2. Perform the standard svn2git functions:
   svn2git http://plugins.svn.wordpress.org/google-analyticator
3. Once the svn2git has completed delete the branch from the local git repo:
   git branch -D 1.4
4. Then remove the remote reference from the local git rep. The ref to delete will be the full git ref path. The path can be found by using git show-ref. This is typically 'refs/remotes/svn/<branch_name>'.
   git update-ref -d refs/remotes/svn/1.4
5. Now perform the svn2git rebase as often as needed until you have migrated to git.
   svn2git --rebase