Git rebase will not continue after a delete/modify conflict

I'm in the middle of a rebase of my master to a stage branch

git checkout stage
git rebase master

At some time I deleted two files then modified the two files according to GIT.

warning: too many files, skipping inexact rename detection
CONFLICT (delete/modify): test-recommendation-result.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation-result.php left in tree.
CONFLICT (delete/modify): test-recommendation.php deleted in HEAD and modified in [Bug] Fix test recommender. Version [Bug] Fix test recommender of test-recommendation.php left in tree.
Failed to merge in the changes.
Patch failed at 0015.

I want to say "Yeah git, go ahead and delete those files" so ....

git rm test-recommendation-result.php
git rm test-recommendation.php
git rebase --continue

Git says:

Applying [Bug] Fix test recommender
No changes - did you forget to use 'git add', Stupid?

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

I say "Don't call me "Stupid" and just do what I told you to do!"

We are now at a standoff. Who is right and how do I fix this?

do git add -A followed by git rebase --continue. This should add all changes - including your removal of the files and then continue.

There is no guarantee that the commit didn't have other files that did not conflict and should be merged. git rebase --skip would lose those files. You don't want that.

When all else fails, read the message.

This patch is trying to modify two files, but they have already been deleted; deleting them again did nothing.

Just run git rebase --skip.

I hit this when a commit added a binary file that conflicted with an existing file.

I got by it by:

• deleting the existing file,
• making a single character change to a comment in a different file, and
• "git add" ing that irrelevant change.

Git was happy again. :)

There is not one magic sequence of commands to always run to solve this situation. If there were, GIT's developers would just perform that action and not bother the user.

Consider that this error can also happen if you're cherry picking / transplanting / backporting changes that affect a file that was re-factored or renamed.

For example, say that you have branch called support/1.0 that looks like this:

com.somewhere.package-a/
  MyClass.java
  MyOtherClass.java

Now, suppose that between versions 1.0 and 1.5, this got refactored. So now release/1.5 looks like this:

com.somewhere.package/
  a/
    MyClass.java
    ANewClass.java
  b/
    MyOtherClass.java

Now, let's say that you have a feature branch from release 1.5 that you're trying to back-port to a feature branch based off of support/1.0. In that commit, there were changes to all three files from release 1.5 (MyClass.java, ANewClass.java, and MyOtherClass.java).

If you try to use rebase or plain cherry pick to help with the back-port, one of two things may happen:

• If the files got renamed as part of the changes being transplanted, or among the immediate parent commits of the changes being transplanted, GIT's built-in rename detection may catch that these files are descendants of the files with original names, and simply apply the changes to the original files.

• If the files got renamed sufficiently far back in the history of release 1.5 (after release 1.0 shipped), GIT will tell you that the files were deleted in release/1.0 because it doesn't know what files in 1.0 correspond to the changes from 1.5.

ANewClass.java will almost certainly trigger the error about having been deleted, unless it was added in one of the changes being back-ported.

Hence, because code might get lost if you blindly follow one set of commands to resolve this situation, that's why GIT prompts you for manual guidance.

as my problem:

when I did git add . all of my changes disappeared. I needed to change any document (just to add little change, for example adding comment) and do git add . than git rebase --continue worked for me. It is a know bug with git

If you've done something like me where it's because the file should have been ignored and at some point it wasn't - so it ended up in source control, delete the files from the filesystem and then abort the rebase.

After that you can restart and not get this error.

It's not an ideal solution, but unfortunately I didn't find any other acceptable remedy for this situation once it occurred.