CODEWITHSUNDEEP
gitsvnmergegit-svn
vertti
vertti

Reputation: 7889

Git-svn merge and checkout --theirs

I unfortunately have to work with an SVN repository at work. I do this via git-svn. Now, after I've made changes, commited them and my git-svn "pull" alias:

!git svn fetch && git svn rebase -l

Now if there's a merge conflict that I don't want to resolve, my instinct is to do:

git checkout --theirs conflicting_file
git add conflicting_file
git rebase --continue

But, now, instead of having the conflicting_file from some other developer, it seems there's now the conflicting_file that was previously in my index.

What exactly happens here and what's the correct way of doing this?

Upvotes: 0

Views: 636

Answers (1)

Tom Panning
Tom Panning

Reputation: 4772

I think @poke had it right: "theirs" and "ours" are swapped in your mind vs git's behavior. When you do the svn rebase, your current branch ("ours") is the replication of the svn branch and the changes that are being merged/rebased in ("theirs") are the ones that you made locally. When I use git-svn for the same purpose, I put my stuff on a separate git branch and only bring it into the svn branch when I'm ready to do a 'svn dcommit'. Doing that would make the theirs/ours issue more clear in your mind, and also keeps you from having to deal with conflicts until you're ready to.

Upvotes: 2

Related Questions