Merge branch that was created with the same name as deleted one

We use Subversion as primary VCS. And I use Git as convenient client. And now I failed to merge feature branch into release branch correctly.

Originally feature branch (feature) was created from release branch (Release1.0). Later it was realized that Release1.0 was closed and now the feature should be developed based on Release2.0.

No problem.

git rebase --onto Release2.0 HEAD~30

Some commit to match code evolution in Release2.0 branch

git rebase -i HEAD~14

At this point I decided not to dcommit changes into svn, but keep all development history in feature branch and do merge with release branch (since later I will probably cherrypick this into another place)

svn rm ....feature
svn cp ....Release2.0 ...feature -m"Feature based on Release2.0"
git svn fetch && git svn rebase
git branch tmp Release2.0 && git checkout tmp
git rebase --onto feature HEAD~35
git checkout feature && git merge tmp
git svn dcommit

To keep svn:mergeinfo in sync I did the actual merge in svn

svn merge -rxxx:yyy feature
git-svn  fetch && git svn rebase

Done? No! The feature branch and Release2.0 branch wa开发者_StackOverflow社区s not merged according to Git. The Release branch just got one additional commit.

The problem is: though the feature branch was deleted and that re-created from another place, the Git shows merge at this point. Thus it refuse to show merge operation (there are commits that was not merged, but they are from deleted part of branch) So i should use another name when creating feature branches in such cases to avoid such problems.

Well, I’ve got the lesson and now I know how to avoid this in future, but is it possible to fix this right now or is it possible to workaround this in other way in future? I've tried to change manually svn:mergeinfo it works but this means I need mark all commits till branching point as merged in svn:mergeinfo.

This seems to confirm the limitations of git-svn regarding rebase, as presentated in its CAVEATS section:

For the sake of simplicity and interoperating with Subversion, it is recommended that all git svn users clone, fetch and dcommit directly from the SVN server, and avoid all git clone/pull/merge/push operations between git repositories and branches.

You can recreate the merge information on SVN side, but Git would not reflect the merge after git-svn fetch && git svn rebase.
By default, git-svn doesn't care about merginfo.

However, "Can git-svn correctly populate svn:mergeinfo properties?" mentions

the current state of affairs with git-svn has changed since it was asked.
Specifically, in git 1.7.5, there is some limited support for setting the svn:mergeinfo when dcommitting back to svn.

git svn dcommit now accepts the -mergeinfo=<mergeinfo> flag.