Question

This is the scenario:

• I copied my subversion trunk into a tag “A”.
• I then ran ‘git svn fetch’ from my local repository which found the branch point and added it as the remote branch ‘svn/tags/A’.
• Later I removed tag “A” from subversion, and again ran ‘git svn fetch’.
• I did a ‘git branch -rd svn/tags/A’ to remove the dangling remote branch from my local repository.
• At a later junction I created a new tag called “A” in my subversion repository. A ‘git svn fetch’ found the branch point but here’s the problem:

My local git repository thinks that ‘svn/tags/A’ points to the old commits from the deleted branch. I’ve spotted some references to ‘A’ in ‘.git/svn/svn/tags’, maybe they’re screwing with me. But when I fire up another git repository and remove those files before running ‘git svn fetch’ I still get ‘svn/tags/A’ pointing at the wrong commit.

Is there any way of clearing out a remote subversion branch and rereading it into my local git repository?

Edit: I’ve sort of gotten this to work, but I’m not really sure of the mechanics of it.
I moved out the references in ‘.git/svn/svn/tags’ to branch ‘A’, then did a ‘git svn reset -r 1000’, where r1000 was the commit immediately before the point I branched. Then did another ‘git svn fetch’ and it looks like it worked.
‘svn/tags/A’ now points to the new commit.

Answer 1

git svn reset allows to change rev_map and refs/remotes/git-svn which would allow git to rebuild its reference to the new SVN tag.
Note: git svn update does not exist.
git svn rebase or better: first git svn fetch should be used here, with a potential git rebase --onto as mentioned in the documentation, if you did some work on the git side.