Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

I can't git rebase --interactive anymore

Tags:

git

git-rebase

I'm having a serious problem trying to do git rebase --interactive on my repo. I get the cryptic error fatal: ref HEAD is not a symbolic ref, and my rebase ceases to function. I must git rebase --abort to get back to a good state.

Here are the output(s) I receive: https://gist.github.com/d38f1e2d2ec9bc480b6f

What I've been told in the past is that this is due to the fact that I'm in "detached HEAD" mode, but how would I have gotten into the rebase in the first place if I was in that mode? I'm most certainly starting in master, then running git rebase --interactive and modifying the git-rebase-todo text file to what I want. And then this error happens.

I've asked everyone here at work, and some people @ #git on freenode. No one seems to truly understand my problem or know what the solution is. Googling for that error produced nothing, relevant searches on StackOverflow have proven nothing. I can't seem to figure this out, and it's really lame going from squashing every commit I push to master to now pushing every little change I make as its own separate commit.

like image 228
tubbo Avatar asked May 07 '12 20:05

tubbo


People also ask

How do I save a git rebase interactive?

Press the Esc key, type :wq! and press Enter key to save and exit the document.

How do I get to interactive in rebase mode?

You can run rebase interactively by adding the -i option to git rebase . You must indicate how far back you want to rewrite commits by telling the command which commit to rebase onto. Remember again that this is a rebasing command — every commit in the range HEAD~3..

What is the problem with git rebase?

git rebase rewrites the commit history. It can be harmful to do it in shared branches. It can cause complex and hard to resolve merge conflicts.


1 Answers

During a 'git rebase' the ref that you are rebasing off of is checked out. If that ref is a commit then you will get a detached head; if it is a branch reference then that branch is checked out. If during the course of a commit a FATAL occurs, then you are left with a working directory in a munged state. For example, if you were on branch Foo and you tried to rebase off of Bar, then after a FATAL you will be at Bar or somewhere after Bar with a few rebase commits applied. You recover by checking out Foo as simply.

git rebase --abort 

or, if the rebase is really wedged (see reference below), as:

git checkout -f Foo

After that, you can safely try the rebase again to try to debug why the FATAL occurs. Here is a case where rebase fails when running out of memory and 'git rebase --abort' doesn't work.

like image 60
GoZoner Avatar answered Oct 16 '22 16:10

GoZoner