Git rebase --continue complains even when all merge conflicts have been resolved
I am facing an issue that I am not sure how to resolve.
I did a rebase against master from my branch:
git rebase master
and got the following error
First, rewinding head to replay your work on top of it...
Applying: checkstyled.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging AssetsLoader.java
CONFLICT (content): Merge conflict in AssetsLoader.java
Failed to merge in the changes.
Patch failed at 0001 checkstyled.
So I went to my favourite editor, fixed the 1 line conflict, saved the file and did a git status and got the following output:
# Not currently on any branch.
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: PassengerContactHandler.java
#
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: AssetsLoader.java
#
I did a git add AssetsLoader.java and a git status and got the following:
# Not currently on any branch.
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: AssetsLoader.java
# modified: PassengerContactHandler.java
#
and when I did git rebase --continue I get:
git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add
I know I can skip the patch and continue the rebase, but I am not sure if the changes in PassengerContactHandler.java will be rebased into my branch or not.
so I am not sure, How should I proceed?
Edit: Could it be that the file with the resolved conflict is exactly like the original version?
Thanks a lot, Lucas
Edit, it just happened to me again:
It just happened to me again,
(307ac0d...)|REBASE)$ git status
# Not currently on any branch.
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: assets/world/level1/Level-1.xml
# modified: George.java
# modified: DefaultPassenger.java
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# mb-art/originalAssets/27dec/
((307ac0d...)|REBASE)$ git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add
git --version
git version 1.7.1
Answer
This happens because when fixing a conflict, you removed all code in the patch beeing applied to the branch you are rebasing on. Use git rebase --skip to continue.
A bit more details:
Normally, when fixing a conflict during rebasing, you will edit the conflicting file, keeping some or all of the code in the patch currently being applied to the branch you rebase on. After fixing the patch and doing
git add your/conflicted/file
git status
you will get a (usually green) line showing the modified file
modified: your/conflicted/file
git rebase --continue will work fine in this situation.
Sometimes, however, when resolving the conflict, you remove everything in your new patch, keeping only code from the branch you rebased on. Now when you add the file, it will be exactly like the one you tried to rebase on. git status will show no green line displaying the modified files. Now, if you do
git rebase --continue
git will complain with
No changes - did you forget to use 'git add'?
What git actually wants you to do in this situation is to use
git rebase --skip
to skip the patch. Previously I never did this, as I was always unsure what would actually be skipped if I did, it was not obvious to me what "skip this patch" really meant. But if you get no green line with
modified: your/conflicted/file
after editing the conflicted file, adding it, and doing git status, then you can be pretty sure you removed the whole patch, and you can instead use
git rebase --skip
to continue.
The original post said this sometimes works:
git add -A git rebase --continue # works magically?
... but don't rely on this (and be sure not to add leftover files in your repository folders)