I am running a fairly complex rebase that had gone well for the last few commits. I fixed a very small conflict and somehow got stuck in limbo --
╰─$ git status
rebase in progress; onto 99e642b
You are currently rebasing branch 'Vince_issue_157' on '99e642b'.
(all conflicts fixed: run "git rebase --continue")
nothing to commit, working tree clean
╰─$ git rebase --continue Applying: RM debugger No changes - did you forget to use git add?
Shouldn't those two be contradictions? How can I figure out what git doesnt like?
Quick reflog output if that raises any red flags
dc04ac4 (HEAD) HEAD@{0}: rebase: improve warning
f97482a HEAD@{1}: rebase: incomplete test for new warning
e73be23 HEAD@{2}: rebase: warning (that needs tweak) on default lang with no translation problem
99e642b (upstream/master, master) HEAD@{3}: rebase: checkout master
5d8b393 (origin/Vince_issue_157, Vince_issue_157) HEAD@{4}: checkout: moving from master to Vince_issue_157
99e642b (upstream/master, master) HEAD@{5}: reset: moving to upstream/master
Quick recap: The conflicts occurred while Git was trying to copy an existing commit whose subject line is:
RM debugger
That is, during git rebase, which works by copying some series of commits to new-and-improved commits that do the same thing as the originals except for some improvement (e.g., being on a different starting base commit), Git tried to copy that commit, and got some merge conflicts. So rebase stopped with RM debugger not yet applied.
You then did some work in your index-and-work-tree to resolve these conflicts, including git add at the end. Then you ran git rebase --continue.
This message:
$ git rebase --continue Applying: RM debugger No changes - did you forget to use git add?
does not mean there are conflicts. It means that the source code in your index now, ready to be committed as the new-and-improved copy of RM debugger, is exactly the same as the source code in your existing commit dc04ac4 (improve warning), which itself is a copy of some older commit whose subject was already improve warning.
Git dislikes making commits that repeat the same source code. (Git calls these empty commits, although they're not empty at all, they're just immediate repeats.) It dislikes this so much that git rebase refuses to do it at all by default, including after you have resolved any conflicts.
This is sometimes a sign that you resolved the conflict the wrong way: that you accidentally dropped your change. But maybe that is the right thing to do.
If the correct thing to do at this point is to drop the original commit entirely—if there's no change needed now because the new base for the new and improved commits doesn't need any fixing—just run:
git rebase --skip
to tell Git: This commit shouldn't be copied after all.
If you really want the empty commit, you can manually commit it yourself, using git commit --allow-empty, then use git rebase --continue to proceed.