rebasing a heavily-merged branch prior to pushing changes upstream

I have a local branch that tracks an upstream SVN branch, in which heavy development work was done while I was also working on local changes. During that time, I have merged upstream into my own branch frequently, as well as cherry-picked isolated commits and sent them upstream. So, in essence, my history looks like a massive clusterfest:

A--B--C--D--b'-E--F--e'--G--H          (svn)
 \     \        \           \
  a--b--c--d--e--f--g--h--i--j         (mine)

That is, upstream contains the changes from e, and my branch contains all the changes from upstream. Now I'd like to get to

A--B--C--D--b'-E--F--e'--G--H
                             \
                              a--b--d--f'-g--h--i

(with f' being what will then remain of the manual merge resolution). Additional difficulties include a rename in the svn branch which I've also followed in one of the merge commits, where my branch contains changes to the file both before and after the merge.

Any idea how to sanely do this? The obvious git rebase -m svn mine doesn't quite cut it, as it fails to detect the renames, and asks lots of questions about conflicts in lines where the tip of my branch has the exact same contents as the 开发者_如何学Pythonupstream branch.

you can try to (just a wild guess):

git rebase -i --onto H a j
# then remove all commits you don't want (already cherry-picked)
# hope the best :D

another possibility, depending on the number of commits, would be to cherry-pick each commit individually. i think newer versions of git can even cherry-pick commit ranges, i'm not sure about that though