Question

I have been using git-svn lately to manage an old svn repository through git.

I have recently been working in a branch that i created like this:
git checkout -b local-branch svn-branch

I have then since been working in that branch and commiting back to the svn-branch using:
git svn dcommit

Now that it’s time to merge the local-branch back to master i tried to do the following:
git checkout master
git merge local-branch

So far, so good. Now i want to commit the merge back to subversion so i try this:
git svn dcommit

However, now my master is committing back to the svn-branch branch and not the trunk as i would have expected. Is there something i missed or is this kind of merging just not recommended to merge between svn branches like this?

As a side note, i instead did the merging through svn, but i would like to avoid having to use svn as much as possible. What is the preferred way to handle this?

Answer 1

git svn dcommit always sends changes to the url specified in git-svn-id signature that is the latest by first-parent chain of commits in HEAD’s history.

I suppose, your merge was fast-forwarded (i.e. master reference was reachable from local-branch/svn-branch), so it was just set to local-branch by “git merge” instead of merge commit creation.

As a recommendation always use –no-ff option with “git merge” because Subversion has no such concept as fast-forward merge. (you can set this option (merge.ff=true) as default in config [ or branch.master.mergeoptions to “–no-ff” for Git < 1.7.6] but note that “git pull” will become non-fast-forward too if you use more than 1 remote)

And in order to avoid SVN and/or git-svn: if you have an access to your repository server, you may have a look at SubGit project that provides pure Git (not git-svn) interface to Subversion. Even in the case of SubGit –no-ff option is strongly recommended because fast-forward merge (and fast-forward rebase) cannot be distinguished from branch removal and recreation from another commit (this is true for any Git<->SVN translation tool).

But maybe any other reason (I don’t know any other) caused “git-svn-id” with branch URL (instead of trunk URL) in the latest commit message. Anyway make sure that master points to a correct commit.