"fatal: ref HEAD is not a symbolic ref" during interactive git rebase

Question

Got 3 commits - one proper, and then two silly cleanup ones, typos etc. So I want to squash them. Fire away:

git rebase -i HEAD~3

Sounds simple, and it should work - I've tried it after running into a problem, in a brand new repo, and it works as expected. Editor shows 3 commits, pick the top, squash the other two, save and quit, done. If I run in verbose mode, I see more details - git enters the detached HEAD state by checking out the 1st commit I 'picked', then does 'Rebasing 2/3' and 'Rebasing 3/3', apparently creating some temp commits along the way -- and then a success message; editor pops up again at some point, offering me to change the commit message. All's good.

But same command dies in a work repo! 3 commits in an editor, pick-squash-squash.. but this time, I don't see 'Rebasing 2/3', instead the very first line after 'HEAD is now at my-SHA-1', it runs into a fatal!

HEAD is now at 48a6c3d... <commit message>
fatal: ref HEAD is not a symbolic ref

But why would git expect HEAD to be a symbolic ref? Rebase process does detach HEAD - same as I see in my exploratory example - so why then the fatal in this second example, but not in the first one? cat .git/HEAD give me the SHA1 of the commit I've 'picked'...

I've spend several hours reading and researching, but something's just not right here, and I can't find what it is! I suspect that maybe some hooks are responsible (know little about them, and know the problematic repo does have some). Thank you for your consideration in answering this!

Answer 1

Your "work" repo is probably broken somehow. See I can't git rebase --interactive anymore for details.

I'd try running git status in your work repo to figure out what is going on. Then e.g. git rebase --abort, git merge --abort or something like that may be required.

I'd run git fsck, too.

After your repo and working directory is good to go, interactive rebase should work fine. Also note that you may need git rebase --root --preserve-merges ... in case you want to touch the first commit in the repo.

Answer 2

there is also a possibility that git commit was executed instead of git rebase --skip or git rebase --continue

this might have added the unwanted commit.

You may run git reset HEAD~1 and then execute git rebase --continue to fix the issue