Can't find `HEAD` in git rebase conflict?

Question

I am trying to rebase in order to squash commits, and I get a conflict:

<username>:~/path/to/director$git rebase -i HEAD~6
error: could not apply 0111a7a... <commit message>

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
Could not apply 0111a7acsadd9a9d98a9003a560a390a50a22afa3af546f42101... <full commit message>

Then, I do the following to find the conflict:

find . -name "*.py" -exec egrep ".*HEAD.*" {} \;

since I know that I only changed python files, I use the *.py globbing. However, no results show up! Is there a way to find exactly what the problem is?

git status, and git diff are both clean.

Answer 1

Before the answer below, I want to note one thing: if you just want to squash a series of commits into a single commit, the easiest way is usually just to combine git reset --soft with the single desired commit. See this answer by Chris Johnsen and this answer by VonC, and note VonC's last bullet-pointed paragraph.

---

We can't tell for sure what is happening, because you haven't shown us enough information, but here's a common scenario in which git rebase tells you that it cannot apply some commit, yet there's also no modifications shown by git status. This is not the same as your case (you're rebasing your own commits on your own HEAD~6, which makes this less likely), but again we haven't seen enough information from you, so I present this as an example instead.

Let's say that you're rebasing a series of two or more commits. The first fixes the spelling of the word word on line 3 of a text file. The second and any subsequent commits do other with other files. These changes were made on branch bran, but since then you've run git fetch and/or decided to move these to branch master or whatever.

Meanwhile, it turns out someone else also fixed the spelling of the word word on line 3 of that text file, along with the spelling of the word spelling on line 12. Your fix is therefore a subset of their fix. It's not the exact same fix—you fixed just one word, they fixed two—but your fix cannot be applied as the word word is already spelled correctly on line 3 of the text file.

Git can't¹ understand that this is OK. It's up to you to figure out that your fix, while it's different from the "upstream" fix you're rebasing on, is no longer needed. In this case (but not in other cases) you should simply skip the commit.

Here's an example session where this has occurred:

$ * abda13a (master) fix two words
| * 9e7ed64 (HEAD, bran) add a file
| * 144d5a6 fix one word
|/  
* ac7be27 initial

Let's take a look at commit 144d5a6:

$ git show bran^
commit 144d5a66949cdd40fd92b0846d5b0ce00ebcdd8c
Author: [redacted]
Date:   [redacted]

    fix one word

diff --git a/README.txt b/README.txt
index c37e4c4..983e649 100644
--- a/README.txt
+++ b/README.txt
@@ -1,6 +1,6 @@
 This readme file
 has at least one
-wurd
+word
 that is
 misspelled.
 There may be

Now let's look at the tip-most commit of master:

$ git show master
commit abda13a47f5b5d968a09eedaf5cc573ba35a3dee
Author: [redacted]
Date:   [redacted]

    fix two words

diff --git a/README.txt b/README.txt
index c37e4c4..867d98f 100644
--- a/README.txt
+++ b/README.txt
@@ -1,6 +1,6 @@
 This readme file
 has at least one
-wurd
+word
 that is
 misspelled.
 There may be
@@ -9,7 +9,7 @@ words, since
 the point of
 this file
 is to allow someone
-to fix the speeling
+to fix the spelling
 of any
 of the misspelled
 words.

Now let's rebase the current branch (which is bran) onto master, but interactively:

$ git rebase -i master
[the editor comes up with both commits selected as `pick`]
[I exit the editor with the same `pick`s]
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'
rebase in progress; onto abda13a
You are currently rebasing branch 'bran' on 'abda13a'.

nothing to commit, working directory clean
Could not apply 144d5a66949cdd40fd92b0846d5b0ce00ebcdd8c... fix one word

(This is with git 2.3.7, incidentally; older versions don't even note that the cherry-pick has become empty, and simply complain that the commit can't be applied. It's not clear to me why it's advising git reset either; that is not necessary at this point. However, git 2.3.7 is now rather out of date; I should upgrade.)

---

¹This actually depends on other things. With git 2.3.7, it's now smart enough to detect this case for a non-interactive rebase. Using the initial setup from above:

$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: fix one word
Using index info to reconstruct a base tree...
M   README.txt
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: add a file
$ git log --oneline --graph --decorate --all
* c8f1815 (HEAD, bran) add a file
* abda13a (master) fix two words
* ac7be27 initial

In this case, the non-interactive rebase figured out that my "fix one word" was redundant with "fix two words" and simply skipped it, so that the final sequence of commits on bran is really just the one remaining commit, with "fix two words" on master as its parent.

Answer 2

normally git status should show you a file in conflict. You shouldn't be searching for HEAD but for <<<<<<, ====== or >>>>>>.

Since you say that git status is clean, it is possible that your commit has become empty. You can check what is in the commit using

git show 0111a7a

if your commit has become empty, you should skip it, using

git rebase --skip