Overview: This question relates to a git-svn repository.
If I merge the local branch into to current one (the master, which is linked to the remote trunk), this will be possible (at least if the svn remotes are up to date, of course). git's status of the merge will be displayed like we expected. But after pushing the new commits to the remotes (the svn), the merge (visible) status will be removed. As a matter of fact, the local branch ends in its own lifeline and isn't be merged in the master anymore. Additionally, all (merged) commits are displayed a second time (in the master).
This was totally "funny" after merging a bunch of commits of trunk into two other branches. Every commit was shown three times.. ,)
My questions are:
Because Subversion's merge features are very primitive, you should never use git merge into a branch that you intend to push to svn. It's fine to use branching and merging on other branches that are local only (or only pushed to a git remote), but when you want to push commits to svn, you should either rebase or cherry-pick the commits into the branch which is being pushed up to svn. This is a limitation of git-svn (although only because of the way svn works).
The SourceTree Help actually suggests not doing any merges at all in a git-svn repo (that's the simplest rule to understand!) but as I say, using other branches that are local only or pushed to a git remote is actually OK, so long as you only move commits on to the svn tracking branch via linear operations and not merges.