Git rebase merge conflict cannot continue

There are a couple situations where I've seen rebase get stuck. One is if the changes become null (a commit has changes that were already made previously in the rebase) in which case you may have to use git rebase --skip.

It's pretty easy to tell. If you do git status it should show no changes. If so just skip it. If that isn't the case please post a copy of git status and I can try to help further.


Note: Git 2.0.2 (July 2014) has fixed one case where a git rebase --skip would get stuck and wouldn't be able to go on with the current rebase.
See commit 95104c7 by brian m. carlson (bk2204)

rebase--merge: fix --skip with two conflicts in a row

If git rebase --merge encountered a conflict, --skip would not work if the next commit also conflicted.
The msgnum file would never be updated with the new patch number, so no patch would actually be skipped, resulting in an inescapable loop.

Update the msgnum file's value as the first thing in call_merge.
This also avoids an "Already applied" message when skipping a commit.
There is no visible change for the other contexts in which call_merge is invoked, as the msgnum file's value remains unchanged in those situations.


One of the times that I have run into this issue is when doing a git commit after a git add. So, the following sequence will produce the rebase error you mention:

git add <file with conflict>
git commit -m "<some message>"  
git rebase --continue

While, the sequence below runs without any errors, and continues the rebase:

git add <file with conflict>
git rebase --continue

It might be possible that git add -A with the "All" option is creating a similar situation. (Please note, I am very inexperienced in git, so this answer may not be correct.) To be safe, the git rebase --skip seems to also work well in this situation.

Tags:

Git

Git Rebase