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:

To start with, I had this

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

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

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'.

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.

I encountered this very same issue today -- I'm guessing you were using git on Windows, that lovely operating system that thought sharing locks was a good idea. My guess is that the reason it choked on somedir/somefile.cs was that it was open somewhere... this was the cause of my failed rebase. Closing all the open programs I could find, resetting as per the chosen answer, then rebasing, worked without a problem. — Paul d'Aoust
– Paul d'Aoust, Commented Aug 20, 2012 at 19:59

Community · Accepted Answer · 2017-05-23 10:29:40Z

35

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

edited May 23, 2017 at 10:29

CommunityBot

11 silver badge

answered Jan 11, 2011 at 17:55

VonC

1.4m568 gold badges4.8k silver badges5.7k bronze badges

Sign up to request clarification or add additional context in comments.

2 Comments

davidtbernal Over a year ago

Well that was easy. I did a reset, and then just dumbly tried to rebase again, and it worked. shrug

VonC Over a year ago

@notJim: true, but it can be useful to keep ORIG_HEAD in mind when doing those commands. It can come in handy.

Collectives™ on Stack Overflow

Recovering from a failed rebase

1 Answer 1

2 Comments

Your Answer

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

2 Comments

Your Answer

Sign up or log in

Post as a guest

Linked

Related