186

I'm trying to rebase 'dev' to catch up to 'master' branch. 

$ git checkout dev 
$ git rebase master 
First, rewinding head to replay your work on top of it...
Applying: Corrected compilation problems that came from conversion from SVN.
Using index info to reconstruct a base tree...
M       src/com/....
<stdin>:125: trailing whitespace.
/**
<stdin>:126: trailing whitespace.
 *
<stdin>:127: trailing whitespace.
 */
<stdin>:128: trailing whitespace.
package com....
<stdin>:129: trailing whitespace.

warning: squelched 117 whitespace errors
warning: 122 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging src/com/....
CONFLICT (content): Merge conflict in src/com/...
Failed to merge in the changes.
Patch failed at 0001 Corrected compilation problems that came from conversion from SVN.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

$ vi src/com/.....   { fixed the merge issue on one file } 
$ git add -A . 
$ git rebase --continue 
src/com/....: needs merge
You must edit all merge conflicts and then
mark them as resolved using git add
$ vi src/com....      { verified, no >>> or <<< left, no merge markers } 
$ git rebase --continue 
Applying: Corrected compilation problems that came from conversion from SVN.
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

Any ideas?

awm
  • 2,723
  • 2
  • 18
  • 26
  • 1
    Note: there are cases where a `git rebase --skip` could still not work properly. Until Git 2.0.2 (July 2014). See [my answer below](http://stackoverflow.com/a/25107391/6309) – VonC Aug 03 '14 at 17:47
  • With problems like this, sometimes it's best to start the merge over and _be extra careful_ to do everything right (which is not easy). – Brent Bradburn Oct 11 '22 at 04:08

6 Answers6

309

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.

JohnAllen
  • 7,317
  • 9
  • 41
  • 65
Chris Nicola
  • 14,384
  • 6
  • 47
  • 61
  • No that was it, there were "no" changes due. I skipped it and compared the file afterwards it was what it should have been. – awm Jan 19 '13 at 13:04
  • This helped me when my 'git pull --rebase origin master" appeared to get stuck in a loop between needing to resolve conflicts and skip. After a bit more patience, I am fixed, ty! – AnneTheAgile Nov 20 '15 at 14:54
  • 5
    git status returns: " rebase in progress; onto You are currently rebasing branch '' on ''. (all conflicts fixed: run "git rebase --continue") ". git rebase --continue returns no changes whereas git rebase --skip do but in my case I'm getting that situation again and again. Is that right or there's something wrong? – Adil Apr 20 '17 at 11:05
  • Thanks. I was worried `--skip` would do worse than just move on with the changes I made. – jchook Oct 06 '17 at 23:33
  • In my case both Intellij Idea GUI and SourceTree were showing that each file was added into commit, whereas `git status` showed, that there was a file that was modified, but was not added into commit. Performing `add somefile.txt` allowed to continue with rebasing. – azizbekian Oct 26 '17 at 12:31
  • skipping is also the risk of loosing some changes. Git fools sometimes the user ... – Karsten May 19 '20 at 11:06
  • I had the same situation and the reason was that both branches contained the same commit added by using cherry-pick – Pavel Jun 04 '20 at 09:39
21

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.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
Steve Reed
  • 373
  • 4
  • 9
6

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
6

After a rebase with lots of conflicts (long git status) I couldn't figure out what it was that I was supposed to stage. I use Git integrated with PhpStorm and it didn't show any unstaged files.

git add . didn't solve it but this comment recommended calling git diff-files --ignore-submodules. That showed three files I had to specifically git add and that did the trick.

Petr 'PePa' Pavel
  • 520
  • 3
  • 10
3
$ vi src/com....      { verified, no >>> or <<< left, no merge markers } 
$ git rebase --continue

Looks like you forgot to git add your changes...

John Brodie
  • 5,909
  • 1
  • 19
  • 29
  • It was only a "verify" no changes were needed the 2nd time ... git add was right above it. – awm Jan 19 '13 at 02:15
  • Right, you used `git add` and then continued the merge, and it stopped because another file has conflicts, so you need to fix that one, as well. Am I missing something here? – John Brodie Jan 19 '13 at 02:17
  • 1
    It's the same file that is reporting needs merging. ok just for you I'll do another "git add", but it's the same result. – awm Jan 19 '13 at 02:19
  • Thanks! That was my situation: I resolved conflicts but not staged the changes. – Kirill Aug 05 '15 at 10:08
0

I saw this when I had a file that was removed in both branches some number of commits in. I had to git rm the file to get rebase to continue.

I tried to reproduce this but failed to get "cannot continue". In case anyone wants to try their hand, here's my what I tried:

mkdir t
cd t
git init
echo a > a.txt && echo b > b.txt && git add . && git commit -m "+a +b"

git checkout -b no-a
echo b1 > b.txt && git add b.txt && git commit -m "~b1"
git rm a.txt && echo b2 > b.txt && echo c1 > c.txt && git add . && git commit -m "-a ~b +c"

git checkout main
git rm a.txt && echo b0 > b.txt && echo c0 > c.txt && git add . && git commit -m "~b +c"
git log --oneline --graph --decorate --all

git checkout no-a
git status
git rebase main
ls
cat b.txt
git status

git checkout no-a b.txt
git commit -m "-a ~b"
git rebase --skip

git checkout no-a c.txt && git checkout main a.txt
git commit -m "~b +c"
git rebase --skip
ericP
  • 1,675
  • 19
  • 21