Using git-svn in SourceTree: Status of a merged local branch to a remote one

[Jan Philipp]

Overview: This question relates to a git-svn repository.

Situation:

1. I have a checkout of trunk (~= master).
2. I create a new local branch based on the master.
3. I make some commits (at least one) on the new branch.
4. I switch back to the master.

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:

1. Is this a limitation of git-svn beause after pushing/pulling/rebasing the commits/references are lost?
2. Is this a bug of SourceTree?
3. Did I get it wrong?

[stevestreeting · Accepted solution]

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.