Eternal code conflict in git-svn

I’ve been recently working with git-svn and I came across a frustrating scenario in which I’m hit with the same code conflicts over and over again. The recipe is the following

  1. Do a git-svn clone of an svn repository.
  2. Make a git svn clone of it, let’s call it repo1 (it’s a git repository).
  3. Make a git clone of repo1, let’s call it repo2.
  4. Do a native svn checkout of the svn repository, make a change to a file and commit it.
  5. In repo2, make a conflicting change to the same file and commit it.
  6. Pull the change from repo2 to repo1.
  7. In repo1, do a git svn rebase.  It will fail with a code conflict.  Resolve the conflict and run git svn dcommit.
  8. Pull changes from repo1 to repo2.  It will fail with a code conflict.  Resolve the conflict.
  9. So far so good.  All conflicts are resolved.
  10. In repo2, make an unrelated change to the same file in which the conflict has previously occurred.
  11. Pull the change from repo2 to repo1.
  12. Do a git svn dcommit.

In my experience, the last git svn dcommit fails with a code conflict – the same that initially occurred.  Moreover, even if I resolve this conflict and dcommit my new change, any subsequent changes to that file will result in the same code conflicts cropping up again and again.

I’ve written a script which reproduces the issue for anyone who would like to examine it and/or propose a recovery procedure, a fix or a workaround.


Author: automatthias

You won't believe what a skeptic I am.

6 thoughts on “Eternal code conflict in git-svn”

  1. I tried to use it, but it might be because I don’t know how to use it yet.

    From what I’ve read so far and talked to people on #git, it’s essentially a case of recovering from an upstream rebase. The solution is to use git rebase –onto, with the right parameters. I didn’t find the right parameters so far.

    I also read that pulls, pushes and merges from remote repositories are not supported by git-svn. You can check out a svn repository to git, but you can’t further clone it and merge changes across your new git repos.

  2. The problem is not about resolving one conflict. It’s about a situation in which the way git-svn bindings are done causes the same code conflict to reoccur. For example, when somebody else commits to svn, and I call “git svn rebase”, a previously resolved code conflict reoccurs, even though I haven’t edited any files.

Comments are closed.