220

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
Lucas
  • 2,340
  • 2
  • 15
  • 7
  • That's the full output of `git status`, right? No missing section below it? – Cascabel Dec 15 '11 at 18:28
  • `git-rebase` should never report that there are unresolved conflicts if there aren't any. If you can manage to reproduce the problem in a simpler test case, it'd be much easier to debug, but still, if you have `git status` reporting no conflicts when `git rebase --continue` does, and your version of Git is current, you might try emailing the Git dev mailing list at git@vger.kernel.org with as much diagnostic information as you can get. – Cascabel Dec 21 '11 at 22:55
  • 2
    It just happened to me again, (307ac0d...)|REBASE)$ git status # Not currently on any branch. # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: assets/world/level1/Level-1.xml # modified: George.java # modified: DefaultPassenger.java # # Untracked files: # (use "git add ..." to include in what will be committed) # # mb-art/originalAssets/27dec/ – Lucas Dec 27 '11 at 21:26
  • I think you should use GITKRAKEN, it will help you in resolving your conflicts – Nikhil Bhardwaj Apr 16 '20 at 03:05
  • I just cloned a linux repository and it went directly into "You are currently rebasing". git rebase --quit was the only thing that fixed it – Brain2000 Mar 22 '23 at 10:14

11 Answers11

179

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

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)

jonasfh
  • 4,151
  • 2
  • 21
  • 37
  • 1
    I seemed to have the same issue and same solution, also seemed magical! – bspink Apr 30 '15 at 01:53
  • I had the same issue, it seems like if you refactored in the rebased branch and added new files, and then the merge resolution process made changes to those new files, you need to explicitly git add them again. – Ibrahim Nov 18 '15 at 02:38
  • 1
    Do not do this unless you want to track all the junk files to your repo. – Jed Lynch Mar 23 '17 at 20:02
  • `git add ...` gets really annoying to type after changing a heap of files with long paths. Is there a `git add --all-the-files-i-changed` I can run before `git rebase continue`? – jozxyqk Aug 05 '17 at 01:45
  • 22
    To be careful when using the command git rebase --skip, you may lose your work (edited files) – Youness Marhrani Jul 08 '19 at 11:54
  • 7
    While `--skip` is the right thing to do when the conflict resolution results in no changes for the commit, that is not the case in this question. Notice that the original question has several files with changes in the staging area. – agbodike May 13 '20 at 21:02
  • 1
    it fails you can just add a dummy comment, then git add . and it will detect that the file change. Then git rebase --continue and it will succeed. This is when you, for example, accept the whole incoming block and delete yours. – John Nov 26 '20 at 16:04
  • 6
    I stop doing this altogether after I noticed some changes I made were dropped. Use with caution. – jperl Feb 11 '21 at 09:54
  • 5
    This destroyed conflict resolutions that I had spent hours on and I have no idea how to get them back. – Andrew Puglionesi Sep 02 '21 at 04:21
  • 4
    I had a single file with a conflict during rebase. I resolved it, but then made a bunch of other changes before attempting to continue the rebase. Using the "--skip" as outlined here, resulted in ALL of my changes being destroyed and it didn't rebase anything. Had to restore using reflog and lost at least an hour of work. Be careful – NSjonas Sep 08 '21 at 20:19
  • 4
    in the general case this NOT a good solution: when you have modified more files, and doing `git rebase --skip` you will lose all the changes – Andrei Diaconescu Jan 06 '22 at 08:56
  • works flawlessly – Gaurav Feb 16 '22 at 18:38
  • 2
    Do **NOT** do `git rebase --skip` unless you are pretty sure you have **absolutely nothing** to commit. – Zhwt Mar 08 '22 at 15:13
  • 2
    If you want your commit back after `git rebase --skip`, use this solution: https://stackoverflow.com/a/38959162/6642154 – Zhwt Mar 08 '22 at 15:15
  • 3
    I lost all my changes when use --skip. – Big Disgrace Jul 04 '22 at 14:55
  • This gave me git-status: `HEAD detached from ` and it looks like my work is gone – Paul Oct 28 '22 at 16:58
34

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>
ScottyBlades
  • 12,189
  • 5
  • 77
  • 85
26

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.

acme
  • 14,654
  • 7
  • 75
  • 109
  • 1
    This actually helped me at git v2 - not because the bug came back, but because the rebase had so many changes to commit that I didn't notice there was one file missing `git add`. `git diff` showed that, and I could move on :) – igorsantos07 Jun 14 '21 at 00:47
8

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

git add -A
git rebase --continue
gsalgadotoledo
  • 2,666
  • 1
  • 25
  • 22
  • This fixed it for me. I use the built-in IntelliJ git integration but for some reason it sometimes does not properly add after resolving conflicts... `git rebase --skip` has screwed me over multiple times already with this problem – Jelle den Burger Apr 06 '22 at 13:17
  • And I end up again here, my god this IntelliJ git integration is weird – Jelle den Burger May 03 '22 at 13:25
7

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

primulaveris
  • 966
  • 14
  • 20
  • 1
    This did the trick for me. I checked Sourcetree after getting the message described in the OP, and immediately saw the two files mentioned in the command window there as unstaged. Staged the files, ran "git rebase --continue" and I was back on track. – Mass Dot Net Oct 18 '18 at 15:08
5

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.

Batkins
  • 5,547
  • 1
  • 28
  • 27
  • Just figured it might be easier and also would allow you to avoid situations like this in the future. – Batkins Dec 15 '11 at 17:12
  • 1
    You saved my evening. Though it's a simple tool, but I'd never be able to figure out how to solve my conflicts without this tool. – eonil Mar 20 '17 at 12:55
4

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.

carpii
  • 1,917
  • 4
  • 20
  • 24
  • 1
    I had a similar problem. Nothing else here worked for me, but just doing 'git commit' and then aborting seemed to magically resolve whatever the discrepancy there was, and then I was able to 'git rebase --continue' successfully. – pattivacek Aug 06 '12 at 20:11
  • Just for the record, as I have been struggling with similar issue recently, `git rebase` accepts `--no-verify` option. However, it omits only the `pre-rebase` hook, but this option is not applied on the subsequent calls to `git commit`. – pkrysiak Feb 23 '16 at 06:29
  • Contains a valid point (commit changes) but too verbose for a good answer. – Jack Miller Nov 26 '19 at 08:44
  • I had the same issue. "git rebase --continue" said that there were merge conflicts outstandingn "git mergetool" said "No files need merging" !! I just had to do a "git add ." and then rebase *would* continue... – Mike Gledhill May 30 '23 at 08:30
4

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.

Ether
  • 53,118
  • 13
  • 86
  • 159
  • 4
    I did a grep on all the tracked files and there were no conflict markers. – Lucas Dec 15 '11 at 17:09
  • Does `git diff --staged` reveal anything useful? This indicates which changes you are about to commit to resolve the merge conflict(s) at this point in the rebase. There should be an "oops, that's not what I intended to do to resolve this" bit in one of the files. – Ether Dec 15 '11 at 17:14
  • 5
    Git doesn't look for merge conflict markers when you try to move on. It just checks to see that the index is in a clean state. If you staged a file that still has conflict markers in it, you're indicating that you want to commit it with them in it. It's probably always a mistake, but it'll let you do it. – Cascabel Dec 15 '11 at 18:27
  • @Ether this is not the reason at all. You can `git add` a file even with conflict markers in it. After all, such files may be perfectly legal! – fge Dec 15 '11 at 18:50
  • @Jefromi: a ha, good to know! I always assumed that the markers were checked for, and one would need to --force past it if it were intentional. – Ether Dec 15 '11 at 19:25
2

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.

Ghislain
  • 69
  • 7
1

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.

Robin Green
  • 32,079
  • 16
  • 104
  • 187
  • This should be marked as accepted answer. I could locate the conflicting files that were apparently not added. The accepted one is very dangerous. – jperl Apr 26 '22 at 11:17
1

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.

Ahmad Shahwan
  • 1,662
  • 18
  • 29