54

What is the best way to resolve a conflict when doing a git svn rebase, and the git branch you are on becomes "(no-branch)"?

Andreas Grapentin
  • 5,499
  • 4
  • 39
  • 57
csexton
  • 24,061
  • 15
  • 54
  • 57

2 Answers2

90

While doing a git svn rebase, if you have merge conflicts here are some things to remember:

1) If anything bad happens while performing a rebase you will end up on a (no-branch) branch.

2) If you run git status, you'll see a .dotest file in your working directory. This is safe to ignore.

3) If you want to abort the rebase use the following command.1

git rebase --abort

4) If you have a merge conflict:

  1. Manually edit the files to resolve the conflicts
  2. Stage any changes with git add [file]
  3. Continue the rebase with git rebase --continue2
    • If git asks: "did you forget to call git add?", then the edits turned the conflict into a no-op change3. Continue with git rebase --skip

You may have to repeat this process until the rebase is complete. At any point you can git rebase --abort to cancel and abandon the rebase.

1: There is no --abort option for git svn rebase.

2: There is no --continue option for git svn rebase.

3: This is very strange, but the files are in a state where git thinks they are the same after that particular patch. The solution is to "skip" that patch on the rebase.

csexton
  • 24,061
  • 15
  • 54
  • 57
  • 3
    just got hit with the no-op change thing, really odd – Sam Saffron Jun 07 '09 at 01:16
  • 3
    Thanks for the --skip tip, didn't even consider it. – bojo Aug 25 '10 at 07:49
  • The whole git rebase --skip thing caused me a bit of grief since I ended up losing my changes quite a few times in my attempts to resolve the conflict. In hindsight I probably should have made a local branch and put my changes in that instead of relying on git stash. I didn't do so because I had read that there are problems with merging branches in git svn, but I think that's to do with trying to merge *svn* branches that you replicate in your local git copy. – trafalmadorian Oct 09 '12 at 08:35
  • I did a merge from remote/trunk into our team's working branch, and I ended up having to resolve the conflicts twice, once on merge, then again when I did a 'git svn rebase'. What did I do wrong? – Quartz Jul 24 '13 at 17:49
  • I know that this is old question, but I hope someone will answer. I imported svn repo using `git svn`. Once made some changes under `git`, but people still work on `svn` so I have to fetch their changes. Everytime I do `git svn rebase` I have to go through this whole process of resolving same "conflicts". How to avoid that? `rerere`did not help. Thanks in advance. – ex3v Jul 02 '14 at 13:09
  • 1
    @csexton your link to harrys blog is dead – smali Nov 15 '14 at 07:15
27

You can use git mergetool to view and edit the conflicts in the usual fashion. Once you are sure the conflicts are resolved do git rebase --continue to continue the rebase, or if you don't want to include that revision do git rebase --skip

1800 INFORMATION
  • 131,367
  • 29
  • 160
  • 239
  • 6
    This helped, thanks. So others don't have my problem.... let `mergetool` stage your changes, but don't `commit` them. Simply call `git rebase --continue` with your staged changes. – slf Aug 10 '12 at 14:34