Git rebase --continue complains even when all merge conflicts have been resolved

Question

I am using version 1.7.1 of Git. I tried using git rebase master to rebase against master from my branch. I got an error because there was a merge conflict:

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.

After manually editing the file to resolve the conflict, I got this result from git status:

# 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
#

Then, after git add AssetsLoader.java, I tried again, getting:

# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   AssetsLoader.java
#   modified:   PassengerContactHandler.java
#

But then git rebase --continue resulted in:

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 will the changes in PassengerContactHandler.java will be rebased into my branch? How should I proceed?

Could it be that the file with the resolved conflict is exactly like the original version?

Answer 1

In my case, some files are automatically changed during rebase. They are shown as "Changes not staged for commit" in git status (red files). After revert those files, The rebase works well.

Answer 2

My issue was that I forgot to add all the files to the stage.

git add -A

Answer 3

this isn't exactly an answer, but a work-around that got me moving again. I renamed the branch I was working on, created a new branch off my target branch, and then just cherry picked all my commits onto it (insert eye roll). If you already have a PR/MR, then you should be able to force push and you're good.

Answer 4

When fixing a conflict, you removed all code in the patch being applied to the branch you are rebasing on. If you are sure you have added all your changes using git add: Use git rebase --skip to continue.

As Youness Marhrani mentioned in their comment, be careful when using the command git rebase --skip as you may lose your work (edited files).

When in doubt

To make sure you dont lose any work:

• Abort your rebase git rebase --abort
• Then create a new branch git checkout -b my-rebasebranch
• Rebase your new branch instead: git rebase origin/main (or whatever)

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'?

If you are sure you have added all your changes, 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)

Answer 5

Seems to be a bug in Git 1.7

Here's a good article on how to solve this. (link doesn't seem to work anymore in 2022)

Basically it should work, if you do a

git diff

after resolving your conflicts and then

git rebase --continue

should work.

Answer 6

The accepted answer is misleading. It causes more troubles that it may save (refer to comments).

I realized that git rebase --continue didn't work for me because I had some local files modified but not staged. Running the following suppressed my local, unstaged modifications. So please be careful that this is what you want.

git checkout .

If you want to stage modifications instead, run git add <name of the file>.

If you want to stash (shelve) modifications, run git stash -k.

Running git rebase --continue should work after either of these commands.

If you choose to stash, run git stash pop (after git rebase --continue) to restore modifications.

Answer 7

If you are using magit (a popular emacs frontend to git), this error message can be shown due to an obscure bug in magit. I'm not exactly sure what triggers this bug, but for me it was that only the line endings were changed for a file, and so magit didn't display the file as a conflict. So I thought there were no conflicts remaining, but there were. Running git status at the command line allowed me to see the conflicting file, and I could then run git add filename and then git rebase --continue.

Answer 8

I got this warning when I had unstaged files. Make sure you don't have any unstaged files. If you don't want the unstaged files changes, then discard the changes with

git rm <filename>  

Answer 9

Once you fixed your changes you might forget to run 'git add -A'

git add -A
git rebase --continue

Answer 10

I just stumbled on the issue. I would not git rebase --skip because git status clearly show modifications stagged, which I wanted to keep. Though I had some extra files that came unexpectedly. I resolved with

git checkout .

to remove unstagged modifications, then git rebase --continue succeeded.

Answer 11

After fixing the conflict, make sure the changed files(s) are added to your staged files. This solved the problem for me.

Answer 12

Ive just had this problem, and whilst I think there might be a few causes, here's mine...

I had a git pre-commit hook which rejected commits under certain conditions. This is fine when committing manually, since it will display the output of the hook, and I can either fix it or choose to ignore it using commit --no-verify.

The problem seems to be that when rebasing, rebase --continue will also call the hook (in order to commit the lastest bout of changes). But rebase will not display the hook output, it'll just see that it failed, and then spit out a less specific error saying 'You must edit all merge conflicts and then mark them as resolved using git add'

To fix it, stage all your changes, and instead of doing 'git rebase --continue', try a 'git commit'. If you are suffering from the same hook problem, you should then see the reasons why its failing.

Interestingly, whilst git rebase doesn't display the output from git hook, it does accept a --no-verify to bypass the hooks.

Answer 13

You missed a merge conflict in AssetsLoader.java. Open it up and look for conflict markers (">>>>", "====", "<<<<<") and then do git add again. Do a 'git diff --staged' if you're having difficulty finding it.

Answer 14

Try running this in your command line:

$ git mergetool

Should bring up an interactive editor allowing you to resolve the conflicts. Easier than trying to do it manually, and also git will recognize when you do the merge. Will also avoid situations where you don't fully merge by accident that can happen when you try to do it manually.