git rebase repeatedly asking me to run `git rebase --continue`

Question

I am on my feature branch my-feature, I run rebase develop branch:

(my-feature)$ git rebase develop

Terminal shows a bunch of conflicts, and it is in detached mode now:

(detached*)$

I resolved those conflicts in detached mode and committed them. Then, I run git rebase --continue, but now git again prompt me the following:

(detached*)$ git rebase --continue
Applying: my-feature my commit message
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.

Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

So, I again run git rebase --continue, but the same message shows to me, it is endless as long as I run git rebase --continue. Why? So, what am I supposed to do after I resolved conflicts to rebase to develop branch?

Possible duplicate of [Completely cancel a rebase](https://stackoverflow.com/questions/22289345/completely-cancel-a-rebase) — Lasall, Aug 08 '19 at 12:40
I updated my question now. I am asking a different thing than how to undo rebase now. — Leem, Aug 08 '19 at 12:50

score 5 · Accepted Answer · edited Mar 31 '22 at 16:31

5

When resolving a conflict on a rebase, you should not commit them, let the rebase handle the commit part*.

_{*Unless you are in an interactive rebase, where you can stop for amending commits.}

Once you have edited the conflictual files you must add them (not commit) and then you can git rebase --continue. Here is an example:

git rebase develop
# conflict
vi file-with-conflict
git add file-with-conflict
git rebase --continue

This will continue rebasing to the next step (next commit), and if there is a new conflict, you will have to resolve it the same way. And so on until there is neither conflict to solve nor commits to rebase.

In your case, you may need to first git rebase --abort to get a clean slate, and then try again to rebase.

edited Mar 31 '22 at 16:31

bloody

1,131
11
17

answered Aug 08 '19 at 12:52

Ulysse BN

10,116
7
54
82

I added and commited. I mentioned it in my question. I am doing exactly the steps you mentioned except I didn't use `--amend --no-edit` in my commit command. – Leem Aug 08 '19 at 12:55
Then my guess is there is one file that has not been edited properly, could you show the result of `git status` (or better `git status -sb`)? – Ulysse BN Aug 08 '19 at 12:56
Oh I just saw your edit. The `--amend` part is really important, since it tells git not to add a new commit but to fix a rebase. Another solution is **not to commit**. I've editer my answer for clarification. – Ulysse BN Aug 08 '19 at 13:01

score 5 · Answer 2 · answered Aug 08 '19 at 17:35

You already accepted an answer, but let me add this, with my own emphasis:

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.

Sometimes, while rebasing—which means copying a series of commits—you will find that one of the commits that Git thought was still required, was in fact not required.

Consider, for instance, this situation:

...--o--*--R--S--T   <-- master
         \
          A--B--C   <-- feature

(The uppercase letters stand in for commit hash IDs. Newer commits are towards the right. You made commits A, B, and C earlier.) You've decided you would like to git rebase your feature onto your master. If it all went as you'd expect, you would end up with this:

                   A'-B'-C'  <-- feature (HEAD)
                  /
...--o--*--R--S--T   <-- master
         \
          A--B--C   [abandoned]

where A' is like A—it makes the same changes, but to commit T instead of to commit *—and B' is like B and C' is like C.

So, git rebase schedules the copying of A, then B, then C. It detaches HEAD (hence "is in detached mode") at T and executes the first copy. If all goes well, you now have:

                   A'  <-- HEAD
                  /
...--o--*--R--S--T   <-- master
         \
          A--B--C   <-- feature

Git then proceeds to attempt to copy B. This copy step fails due to conflicts, leaving you in the state you saw.

You now begin resolving conflicts. Inspecting the first conflict, you see that what what you did in B is already taken care of by commit S, so you choose their code from T, which resulted from their change in S, rather than your code from B. Inspecting the second conflict, you see that what you did in B is already taken care of by commit R, so you take their code from T again. This repeats until you have resolved all conflicts, taking no changes from your own B.

If you now run:

git rebase --continue

your Git will say:

No changes - did you forget to use 'git add'?

No, you didn't forget, you just resolved all conflicts by, in the end, dropping your commit B. So the bold-text advice above applies and you can just run:

git rebase --skip

to tell Git: Yes, drop my commit entirely, and proceed to attempt to copy C now. Assuming that copy works, the rebase will finish and you will have:

                   A'-C'  <-- feature (HEAD)
                  /
...--o--*--R--S--T   <-- master
         \
          A--B--C   [abandoned]

which is not quite what you expected originally, but is what you needed after all.

git rebase repeatedly asking me to run `git rebase --continue`

2 Answers2