Merging with Git: conflicts!
Dramatis Personae:
git-svn rebase: our hero/ protagonist
(no-branch): a mysterious stranger
.dotest: an even more mysterious interloper
Scene I - The Setup
tra-lala-lala
>>mate config/environment.rb
>>git add config/environment.rb
>>git-svn rebase
eek!!
>>CONFLICT (content): Merge conflict in config/environment.rb
merging...
>>mate config/environment.rb (and fix problem...)
>>git add config/environment.rb
Scene 2 - Where it all goes wrong
Well, since we just added, maybe we should just commit.
>>git commit -m "merged conflict
At this point, everyone dies, commits are forever lost and you are left to rot in the bizarre (no branch) land that your $9 git tutorial, or not-yet-published book, never mentioned. Return to start.
Scene 2 --ammend
>> git rebase --continue !!!
Milk & Honey*
(or not. see the postscript)
Scene 3 - Where all is explained
The problem with scene 2 is that once a conflict occurs, git pops you into a new 'branch'-ish thing called (no branch). This is not a regular old branch afaict however. If you were to decide not to fix the conflict and just go on your merry way committing new code you'll be in for a lot of pain. You can tell if you're in this mysterious state by running 'git branch'. On git <>>[jdwyah@silvia sample]$ git rebase --continue
>>Applying: test
>>No changes - did you forget to use 'git add'?
Basically when you committed you essenitally stole your continue's thunder and it isn't happy about it.
Now you can do a --skip instead, and this is also written up here: Larry vs. the Git Rebase Merge Conflict but from what I've been able to reproduce I think he must've done the commit accidentally like I did and there's no reason not to do the continue instead. It's such a twitch reaction to add then commit I'm guessing that he did the same thing I did. That said, git rebase --skip does work as a way to get out of this mess.
Postscript (--ammend --ammend)
* Note, it might not necessarily be all milk & honey here. You may in fact, be left with... MORE CONFLICTS! Now why might this be? Well, the fact is that you may be rebasing onto your local branch which may have multiple commits. If this is the case, when git goes to replay your changes after the rebase merge it may well conflict multiple times: once for your first local commit, once for your second, etc...
It's quite possible to think that you're losing your mind at this point, since you can continue to get conflicts for the same darn file over and over again, but if you do keep merging things you should eventually make it out of the rabbit hole. Hodgies merge option is probably a good solution here, or alternatively you could merge your local commits into one big commit.
git-svn rebase: our hero/ protagonist
(no-branch): a mysterious stranger
.dotest: an even more mysterious interloper
Scene I - The Setup
tra-lala-lala
>>mate config/environment.rb
>>git add config/environment.rb
>>git-svn rebase
eek!!
>>CONFLICT (content): Merge conflict in config/environment.rb
merging...
>>mate config/environment.rb (and fix problem...)
>>git add config/environment.rb
Scene 2 - Where it all goes wrong
Well, since we just added, maybe we should just commit.
>>git commit -m "merged conflict
At this point, everyone dies, commits are forever lost and you are left to rot in the bizarre (no branch) land that your $9 git tutorial, or not-yet-published book, never mentioned. Return to start.
Scene 2 --ammend
>> git rebase --continue !!!
Milk & Honey*
(or not. see the postscript)
Scene 3 - Where all is explained
The problem with scene 2 is that once a conflict occurs, git pops you into a new 'branch'-ish thing called (no branch). This is not a regular old branch afaict however. If you were to decide not to fix the conflict and just go on your merry way committing new code you'll be in for a lot of pain. You can tell if you're in this mysterious state by running 'git branch'. On git <>>[jdwyah@silvia sample]$ git rebase --continue
>>Applying: test
>>No changes - did you forget to use 'git add'?
Basically when you committed you essenitally stole your continue's thunder and it isn't happy about it.
Now you can do a --skip instead, and this is also written up here: Larry vs. the Git Rebase Merge Conflict but from what I've been able to reproduce I think he must've done the commit accidentally like I did and there's no reason not to do the continue instead. It's such a twitch reaction to add then commit I'm guessing that he did the same thing I did. That said, git rebase --skip does work as a way to get out of this mess.
Postscript (--ammend --ammend)
* Note, it might not necessarily be all milk & honey here. You may in fact, be left with... MORE CONFLICTS! Now why might this be? Well, the fact is that you may be rebasing onto your local branch which may have multiple commits. If this is the case, when git goes to replay your changes after the rebase merge it may well conflict multiple times: once for your first local commit, once for your second, etc...
It's quite possible to think that you're losing your mind at this point, since you can continue to get conflicts for the same darn file over and over again, but if you do keep merging things you should eventually make it out of the rabbit hole. Hodgies merge option is probably a good solution here, or alternatively you could merge your local commits into one big commit.