Re: Using git to perform merges between SVN branches

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: May 21, 2008, 18:01 UTC
Message-ID: <20080521180140.GA21231@atjola.homenet>
In-Reply-To: <a5c338c9-7820-41bd-a3a3-36ba5aad4379@l64g2000hse.googlegroups.com>

On 2008.05.21 08:50:33 -0700, davetron5000 wrote:

Show 31 quoted lines

> Working out of an SVN/subversion repository.  Initially cloned it so I
> could work with git via git-svn.  I was given a branch in svn to work
> on.  Created local branches connected to the main trunk and my branch
> via:
> 
> git-checkout -b local-trunk trunk
> git branch local-foo FOO
> 
> where svn_root/branches/FOO is where I'm to commit changes
> 
> commits work fine, etc.
> 
> What I'd like to do, for simplicity, and as a demonstration of git's
> superior merging, is to do the merge of my code to the main trunk
> using git.  My main concern is not getting into a situation where I
> cannot commit to svn (since it doesn't track merges)
> 
> Would something like this work:
> 
> git checkout local-trunk
> git-svn rebase
> git checkout -b merge-foo local-trunk
> git merge local-foo
> # Resolve conflicts, etc.  local-foo now has what should go onto SVN's
> trunk
> git checkout local-trunk
> git merge merge-foo
> # this should work without any conflicts, since I resolved them on
> merge-foo
> git-svn dcommit
> # Now I've merged my changes to the main trunk

You can skip the whole merge-foo thing and just merge local-foo into local-trunk, the second merge would end-up as a fast-forward anyway.

That said, the above should work, given that a) you don't do any rebasing after merging and b) the merge commit is the first commit that gets dcommitted to svn.

I don't remember what happens when there are new revisions in svn since you last ran "git svn rebase", so you might want to try that case on a throw-away svn repo first.

What SVN will see is basically what git would see had you done a "merge --squash", but git will retain the merge information (big plus!).

Björn