Using git-svn: Pull, Merge or Rebase?

Question

I've been fighting the git/git-svn learning curve and last night, as part of that learning curve, I did something very, very bad. I've since gotten it corrected, but I'm hoping to understand the error my ways.

I have an svn repository from which I've cloned the trunk and branches (tags I ignored since we don't work on those). Using git, I created local branches for each of the branches that I currently need to work with:

$ git checkout -b trunk svn/trunk $ git checkout -b feature1 svn/branches/development/feature1 $ git checkout -b maint svn/branches/maintenance/previous-version 

I made feature1 my active branch and made a few changes before getting pulled away for a few days. I cam back to it yesterday wanted to integrate any changes that had been made to the trunk so that I was working with the latest and greatest. What I did was a complete update of all brances first, via git svn rebase (no one else had worked on the feature1 branch). With everything up to date from my svn repository, I tried to rebase.

With feature1 as my active branch, I did a "git rebase trunk" thinking that I would be pulling changes from the trunk into the feature1 branch. Turns out I was very, very wrong. After merging all of the conflicts, I did a git svn dcommit and found that my changes had been applied to the trunk.

My first question is simply where was the core error in my thought process? My second is, after much reading and Googling, I see people espousing pulls, merges and rebases. Given the fact that I want to merge the changes applied in one local branch to another local branch, what should I have done? What's the best practice for this scenario?

Thanks for your help.

Answer 1

The problem you ran into is that the command line syntax for rebase doesn't match your (very reasonable, IMO) expectations.

$ git checkout feature1 $ git rebase trunk 

This sequence adds the unshared feature1 commits onto the HEAD of trunk, and you were expecting that it would place the new trunk commits onto the HEAD of feature1. The syntax actually makes some sense when you know how Git's data model is implemented (which is undoubtedly why it is the way it is). But to me it is the opposite of what I expect, functionally. It's best to learn it as an arbitrary construct and not try to have expectations.

You're right that you understand how to interact with the SVN repo using git-svn. So ignore what you found in Googling about push and pull and merge -- there's a lot of nearly right discussion by people who act as if push and pull and merge are the same in git and svn. Nearly right is still wrong.