Git rebase will not continue after delete / change conflict

Question

I am in the middle of my host rearranging the stage branch

git checkout stage git rebase master 

At some point, I deleted two files and then changed 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 "Yes, git, go ahead and delete these 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!"

Now we are in a confrontation. Who is right and how to fix it?

Answer 1

do git add -A followed by git rebase --continue . This should add all the changes, including deleting the files, and then continue.

There is no guarantee that the commit did not have other files that do not conflict and should be merged. git rebase --skip will lose these files. You do not want this.

Hope this helps.

Answer 2

If all else fails, read the message.

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

Just run git rebase --skip .

Answer 3

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

I recieved it:

• delete an existing file,
• changing one character in a comment in another file and
• "git add that irrelevant change.

Git was happy again. :)

Answer 4

There is more than one magical command sequence that always runs to solve this situation. If it were, GIT developers would simply perform this action and not bother the user.

Please note that this error can also occur if you choose cherry pick / transplant / back up changes that affect a file that has been refactored or renamed.

For example, let's say that you have a branch named 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 it got refactoring. 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 function branch from version 1.5, which you are trying to execute back into a function branch based on support/1.0 . In this commit, changes were made to all three files from version 1.5 ( MyClass.java , ANewClass.java and MyOtherClass.java ).

If you try to use rebase or a simple cherry picker to help with the back-port, one of two things can happen:

• If the files have been renamed as part of the transplanted changes, or between the immediate parent commit of the changes being transplanted, GIT's built-in rename detection can catch that these files are descendants of the files with the original names and just apply the changes to the original files.

• If the files were renamed far enough back in the release 1.5 history (after the release of version 1.0), GIT will tell you that the files were deleted in release/1.0 , because it does not know which files in 1.0 correspond to the changes from 1.5.

ANewClass.java almost certainly cause a delete error, unless it was added to one of the changes that were rolled back.

Therefore, since code may be lost if you blindly follow one set of commands to resolve this situation, why GIT offers you a guide to guide you.