git merge vs rebase using git svn

Question

I am very confused, I have read several posts, blogs and articles and don't know where to go. I am using an svn server repo that I pull down with git svn and work on. I am currently the only person developing this ( i.e. no upstream changes ) .

So i have a local git topic branch vacation, which i need to merge back into master to dcommit, but i don't want to squash all the commits into one big one.

I tried to do a git rebase -i master and it erased 90% of my changes.

do i do a

git checkout master
git rebase vacation
git svn docmmit

Or a

git checkout vacation
git rebase master 
git checkout master 
git merge vacation --ff-only 
git svn docmmit?

I am afraid of that way b/c what happened when i tried before can someone please briefly explain what I should do and why I have to do it that way?

Answer 1

so I think i figured it out.

git checkout vacation
git rebase master 
[ masters's chages put behind this branches, replay every commit ]
git checkout master
git merge --ff-only vacation
git svn dcommit 
[ each change goes into svn as seperate commit ]

I had no upstream changes, but this was exactly what i wanted.

Answer 2

You should merge or cherry-pick into master not rebase.

As for why, its a question of ordering. Rebase implies you want to alter the history to make your topic branch appear before master in the history. If you merge or cherry-pick commits then it will add your commits on top of master.

So a complete cycle would be something like

git checkout -b vacation
[make changes]
git commit -a -m "Commit message"
git checkout master
git merge vacation
git svn dcommit

To explain rebase more fully an example from my personal setup: In addition to master I also maintain a local branch work which I use as the base for my local configuration of out project. It has things like custom property files which I don't ever want to commit. I need to keep this in sync with the master branch so I do this starting from master:

git svn rebase
git checkout work
git rebase master

Now git reconstructs the history of the work branch placing all the local config commits at the head of the stack. It litterally REcreates the branch BASEd on the master branch. If I were to issue

git merge master 

instead of rebasing then the result to the lamen eye would be the same but the history would be very different indeed. The two histories would be resolved, possibly resulting in merge commits, instead of one based on top of the other.