Recovering from a failed rebase

Question

I'm using git svn to get some git goodness with the company-mandated svn server. I just had a rebase go horribly awry, and I"m trying to figure out the best way to recover.

Here's what happened:

1. To start with, I had this

   ---1 (master)     \--B--C--D--E (feature/fix-widgets) 

2. So then I did git checkout master and then git svn rebase on master to pull down those commits. I did not anticipate any conflicts between my feature branch and the master, because the changes were in a totally different folder. So at this point, I think I have this:

   ---1--2--3--4 (master)     \--B--C--D--E (feature/fix-widgets) 

   Where 1--2--3--4 are commits pulled in from svn.

3. Next I do git checkout feature/fix-widgets and then git rebase master. There's immediately a conflict, and some things that don't add up, so I decide to slink away and look at things more carefully. I do git rebase --abort, hoping this will restore me to where I was before the rebase.

4. I do git rebase --abort and receive the following message

   $ git rebase --abort   error: git checkout-index: unable to create file somedir/somefile.cs (Permission denied)   fatal: Could not reset index file to revision 'be44daa05be39f6dd0d602486a598b63b6bd2af7'. 

5. Now I'm not sure what to do. git status shows that I'm on feature/fix-widgets, but I have a whole bunch of staged changed, and a large number of untracked files, which were previously committed. I'd be fine if I could get back E.

Answer 1

You should have a look at ORIG_HEAD

ORIG_HEAD is previous state of HEAD, set by commands that have possibly dangerous behavior, to be easy to revert them.
It is less useful now that Git has reflog: HEAD@{1} is roughly equivalent to ORIG_HEAD (HEAD@{1} is always last value of HEAD, ORIG_HEAD is last value of HEAD before dangerous operation)

So try this git reset to get back to before any rebase:

git reset --hard ORIG_HEAD