Resolving Git Svn Conflicts

Question

I'm using Git-Svn to interact with a Svn repository at work and I can't seem to find a way to effectively resolve conflicts for the life of me. I've read the other questions on this topic, but evidently I need something even more remedial because i always seem to end up in some kind of endless loop. I rebase, use mergetool (meld) to resolve my conflicts and, when I get to the end of all that, I try to do a dcommit and I get a merge conflict during commit error.

I know this feels like a duplicate, but frustration is making me ask again, with some very specific details about how I'm going about this so that hopefully someone can tell me exactly where my process is screwed up.

My setup:

I have a remote branch (svn/trunk), a local branch (trunk) and another local branch that I typically work in (working-trunk). trunk was checked out from svn/trunk and working-trunk was checked out from trunk.

Here's what I've been doing:

1. On my trunk, git svn rebase (returns conflicts)
2. git mergetool
3. [resolve the conflicts for that file]
4. Save the merged file from meld and close meld.
5. git add .
6. git rebase --continue
7. [rinse, repeat]
8. If I get a message asking whether I used git add, I git rebase --skip

When I get to the end of all the reported changes, everything just kind of stops and I guess maybe I'm not sure what to do at this point. Git shows nothing to be committed and I appear to be back on the trunk. Git then allows me to dcommit, but if I try a rebase immediately thereafter, I end up re-resolving the conflicts I just resolved.

There's clearly a critical piece I'm missing here, but I just don't see it and it's causing a lot of problems and frustration. Merges may be easy in Git, but I'm sure not finding that to be the case.

Thanks.

UPDATE: Just wanted to throw out a quick update to describe my workflow in case that's part (or all) of the problem.

To start, after cloning my repository with a svn/ prefix, I have my svn/trunk remote branch. Given that:

1. I git co -b trunk svn/trunk to check out my remote to a local branch.
2. I git co -b working-trunk to create a working branch that I use to create one more degree of separation so that my local trunk can always mirror my remote trunk.
3. I delete the default master branch (when working with svn, I find it easier to think in terms of "trunk" rather than "master").

Once I have all of my branches, my typical workflow looks like this:

1. On working-trunk, I make my changes and commit them.
2. I git co trunk and do a git svn rebase.
3. Assuming new code was rebased, I git rebase working-trunk.
4. git co working-trunk
5. git merge trunk
6. git rebase trunk
7. git co trunk
8. git merge working-trunk
9. git svn dcommit

It's a lot of steps, I know, but that's what everyone here and elsewhere has recommended. Could my fatal flaw be somewhere in that process?

Thanks again.

Answer 1

I'd recommending using git rebase instead of git merge. Svn keeps a linear history and seems to get confused with git branch merges sometimes. Using git rebase ensures a linear history svn understands.

see: http://learn.github.com/p/git-svn.html for a bit more info and guidelines.

Answer 2

I ended up in having the same problem (git svn rebase that returns conflicts). I found out the problem in my workflow. Here is the workflow I/you should follow:

git svn rebase # put all the new commits on top

git svn dcommit # push the new commits to svn (will rewrite each commit message to add the svn tag)

git pull # merge the conflicts due to the commit messages

git push # push the synchronized version to the remote git server

Whenever I forgot to merge the history after dcommit, I have new (fake) conflicts that appear if I do new commits. To solve them, you can either follow the approach you've described above or if it is due to the exact same problem as me, you can also do it in an automatic way by using:

git svn rebase --strategy ours

Answer 3

One may find SubGit's approach a bit easier:

1. Install SubGit into Subversion repository on the server side
2. Use git not git-svn to send changes to SVN repository*

SubGit installation creates a Git counterpart of SVN repository. Clone this repository to your local one; create any branches and push them to remote Git repository, SubGit automatically converts these branches into SVN.

For more details please refer to SubGit documentation and git-svn comparison.

* Works with any Git client.