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.

About these ads

6 Responses to “Eternal code conflict in git-svn”

  1. James Youngman Says:

    Does git rerere help (second time around)?

  2. automatthias Says:

    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.

  3. Rob Says:

    If you are having trouble resolving a conflict check this out: http://www.duchnik.com/tutorials/vc/svn-conflicts

  4. automatthias Says:

    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.

  5. A git-svn workflow « Maciej Bliziński Says:

    [...]  If you use git pull/push and try to commit back to subversion, you will sooner or later fall into the trap that I fell into some time ago.  I’ve since worked out a relatively sane workflow which allows me to work [...]

  6. CB Says:

    Thank you for tip! Does it work with github?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 474 other followers

%d bloggers like this: