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.