Git rebase will not continue after a delete/modify conflict

Question

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?

score 67 · Accepted Answer · edited Nov 26 '21 at 18:36

67

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.

edited Nov 26 '21 at 18:36

Dharman

30,962
25
85
135

answered Apr 01 '11 at 17:20

Adam Dymitruk

124,556
26
146
141

1

You're right in general, but in this case, it appears that we can deduce that no other changes exist. Git would either have complained about other conflicts, or the `rebase --continue` would have worked. – Cascabel Apr 01 '11 at 19:53
That is the exception and not the rule. All devs should do this as it takes care of both cases. – Adam Dymitruk Apr 04 '11 at 18:06
2

You're missing the point. The first step here is "check the output of git status". If it has no conflicts listed, and nothing staged, then skip is the right choice - and add/continue will do nothing, as the OP saw. If it has only staged changes listed, then there wasn't a conflict in the first place, and you can continue (the question would never have been asked). If there are conflicts, the question still would never have been asked, and your answer is dangerous - you need to fix the conflicts before blindly adding everything. – Cascabel Apr 04 '11 at 18:13
3

Short version: there is no single sequence of commands you should always run when a rebase stops partway through. You need to understand what has happened, and act accordingly. – Cascabel Apr 04 '11 at 18:17
Agree to that. But --skip requires the extra look to see if there were other files that did not conflict. the 'add' followed by 'continue' allows you to /just/ look at the conflicts and not worry about the non-conflicting files, if any. We're really being picky here, but it's valuable for someone to see the discussion if they are wanting to learn more about rebase, conflicts and the index :) – Adam Dymitruk May 24 '11 at 05:25
1

I buy your answer, but I'd like to know *why* it's true. Why is it that "git rm" alone isn't enough for git to know that your intent is to confirm removal of those files (and add a remove entry to the index), and what does "git add" after "git rm" really mean? – metamatt Jul 12 '13 at 17:41
git add -A simply states to add the snapshot of the working dir as is and clears any conflict markers in doing so. – Adam Dymitruk Jul 17 '13 at 09:23
2

Be careful if there are untracked files in your repo as `-A` will add them all. In my case, the conflict was in a subdir and I just did `git add subdir`. – Gogowitsch Dec 08 '17 at 07:32
Caution: `git add -A` adds changes from tracked and untracked files. If you have other untracked files, this may just hang for a while trying to add everything. – Ben Dec 14 '18 at 00:47

score 3 · Answer 2 · answered Apr 01 '11 at 16:53

3

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.

answered Apr 01 '11 at 16:53

Josh Lee

171,072
38
269
275

4

no guarantee that there were other files that were merged correctly. rebase skip would lose those changes. – Adam Dymitruk Apr 01 '11 at 17:21
Oh, I thought rebase would not be complaining if other files were merged correctly. – Josh Lee Apr 01 '11 at 17:26
1

The issue is that it complained about the 2 files having conflicts. That commit may have had more than just those 2 files that were changed. If you skip, you skip those as well, not just the ones that reported conflicts. – Adam Dymitruk Apr 01 '11 at 17:55
1

@adymitruk: Those were the only two conflicts reported, so if other files were changed, they'd already be in the index, and `rebase --continue` would not have complained about the lack of files. `rebase --skip` *in this case* is exactly right. – Cascabel Apr 01 '11 at 19:46
it's about covering both cases where there were and were not files in the index with no conflicts. See above comments. – Adam Dymitruk May 24 '11 at 05:27

score 2 · Answer 3 · answered May 30 '13 at 20:20

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. :)

score 1 · Answer 4 · answered Feb 10 '20 at 10:27

1

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

answered Feb 10 '20 at 10:27

x-magix

2,623
15
19

score 0 · Answer 5 · answered Apr 19 '17 at 14:19

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.

score 0 · Answer 6 · answered Jan 25 '21 at 04:30

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.

Git rebase will not continue after a delete/modify conflict

6 Answers6

Linked