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

You should use git svn clone -s to clone complete svn tree, including all branches. From then on use git svn rebase and git svn dcommit in master to deal with svn, and you can create regular git branches for your private use.

Answer 2

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.

Answer 3

I am still confused on the actual workflow required for working with svn. It seems that the dcommit looses information or something because I always need multiple merges but they are for no real difference?? What I need to know is, am i going about this the wrong way in that all i am trying to do is get the changes into svn which in this case it master? Sorry for the large response but I just wanted to post a working example. The basic process is as follows:

• git co orgupdate
• git commit x10
• git co master
• git svn rebase
• git log master..orgupdate
• //see list of changes
• git merge orgupdate
• git status
• git log master..orgupdate
• //no differences
• git svn dcommit
• git log master..orgupdate
• //now differences
• git svn rebase
• git log master..orgupdate
• //still differences
• git merge orgupdate
• git log master..orgupdate
• //no differences
• git svn rebase
• git log master..orgupdate
• //differences again??

So it seems from this situation that there is either some loss of sync between the messages but no data loss?? I am a little confused at what it really happening and if i should be using rebase between the branch instead?