git rebase --continue won't work
Solution 1
If you are in Mac OS X, then first of all you should disable revisiond
, as it can mess with files in your work tree in the middle of rebase, causing unpredictable and broken behavior:
git config --global core.trustctime false
The issue is explained in this article, and big thanks to @nickfalk who pointed it out.
As for your rebase, this kind of situation is not unusual in practice. Let's try to think through the steps of what's happening:
When you rebase the current branch on top of another branch, git moves the HEAD to the other branch, and starts applying the unique commits you have in your current branch.
While replaying one of those commits, you reached a conflict. You resolved it, but as a result there are no changes to commit, nothing to replay in this commit.
Practically, this means that you rejected the changes in the current commit being replayed. So, if you don't need anything from this commit, it's normal to skip it. So git rebase --skip
makes sense here.
Solution 2
I had a similar problem in my project and solved by putting the --preserve-merges option to the rebase command. In my project, this problem was caused by a merge commit, which is an "empty commit". Using git rebase --preserve-merges
it takes the merge commit and continues the merge without breaking the commit tree.
Solution 3
Breath, you're not going crazy! ;-= This is a known bug where OSX (if that is indeed what you're using) is messing with git, it is detailed here (not by me).
Short story (i.e. the fix) is:
git config --global core.trustctime false
Solution 4
I tried all the methods but nothing worked for me. If you are not in the middle of a rebase but git keeps complaining, then try the following. This worked for me for OSX.
rm -fr ".git/rebase-apply"
Solution 5
git add .
will unblock you from this state, but if you resolved all conflicts by accepting the incoming changes, there is no diff to add so git thinks the conflict wasn't resolved as far as the rebase is concerned.
I took a low brow approach that worked without relying on side effects of using mysterious git config changes etc:
- Added harmless content (eg
//
on one line) to each file in conflict (to give git something toadd
) git add .
git rebase --continue
- remove harmless comment
All sorted 🙂
Boon
I manage a team that builds highly-innovative interactive apps and games for mobile and web. I love building things that reach a lot of people make people happy
Updated on August 25, 2022Comments
-
Boon almost 2 years
I did
git rebase master
, fixed the conflicts reported in a file, and thengit add
the file to resolve the conflict. Then I didgit rebase --continue
, and got this:Applying: Fixed unit test
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 prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort".
Any idea what I am missing here? Should I do git rebase --skip?
-
Josh Kovach over 10 yearsI used to have this problem all the time with huge rebases. Thanks for pointing this out!
-
Boon over 10 yearsYes OSX. This fix doesn't do it :(
-
Boon over 10 yearsChecked status, it's not.
-
T. Benjamin Larsen over 10 yearsIt is likely that this will not help with your current rebase. It is already basing itself on the existing information in the file-system. Not sure, but it might just work if you restart the rebase...
-
Boon over 10 years@nickfalk, thanks for answering this. I selected another answer because that's what solves it for me but your answer can very well help someone else.
-
T. Benjamin Larsen over 10 yearsNo worries Boon, hope you are 100% sure that deciding to disregard any changes your mentioned commit had was what you wanted...
-
T. Benjamin Larsen over 10 yearsThis would make indeed make sense if the commit in question was disregarded and none of its changes was accepted as a part of solving the conflict. Taking the below mentioned well-known bug into consideration however, it could also easily mean that you lose the intended changes in said commit...
-
janos over 10 yearsYou're right, I added this info now, and thanks for pointing it out!
-
CommaToast almost 10 yearsThis was driving me crazy. Thank you very much. I would also like to note that you're awesome.
-
Alejandro de Haro over 4 yearsMan, this saved my day. I was using Ubuntu, so any other answer didn't apply to me but yours. Adding the
--preserve-merges
option ended up working flawlessly as git showed me further problems that I had with my tree but that could be fixed up manually. -
Adas Lesniak over 4 yearsIn case of getting changes from single commit (or even few) - it's much better to put them on separate temporary local branch, then checkout your working branch, reset it to before changes, rebase if needed, then cherry pick. That's what cherry pick is for - to not copy things manually.
-
Damian Giebas over 4 yearsGod bless you for this post. It resolved my problem!
-
Gi0rgi0s about 4 years@AdasLesniak that's a really good point! I wish I had thought of that while I was resolving my issues last year
-
Szczepan Hołyszewski about 3 yearsHow can changes be "already rebased" if I am still in the process of rebasing and I haven't finished?
-
nbeuchat almost 3 yearsThat made the trick for me on Ubuntu