Recovering from an aborted git-rebase?

Recovering from an aborted git-rebase?

[Steven Grimm]

Got this from one of the other people here who's using git. Luckily he 
was able to restore his repo from a filesystem snapshot, so no permanent 
harm done, but what's the pure-git way to recover from this? Are the 
revisions in question really gone?

---
I have 3 branches:
master
fql
fql-new
master is basically just the same as remotes/git-svn, fql is a bunch of
changes on top of that, and then fql-new is a new version of FQL so it makes
changes on top of the changes in fql (with the intention being to make it
easy to jump back if I didn't wind up liking the new version).
unfortunately perhaps I made it too easy, as now fql and fql-new are
identical and I can't get the additional set of changes back for fql-new.

Generally when I want to sync up to SVN I just fetch it in master and then
rebase everything to its parent branch - basically my goal being to get git
show-branch to look the same as it did before the fetch.  This time I did
the fetch command in fql-new instead of master, which I'm pretty sure I've
done before with no real harm done.  Anyway, here's what I did:
(in fql-new branch)
dev005:~/www-git$ git svn fetch
<pulls in the usual updates>
dev005:~/www-git$ git rebase fql
Current branch fql-new is up to date.
dev005:~/www-git$ git checkout master
dev005:~/www-git$ git rebase remotes/git-svn
First, rewinding head to replay your work on top of it...
HEAD is now at a5074e5... Fix IE6 display bug on photo_comments
Fast-forwarded master to remotes/git-svn.
dev005:~/www-git$ git checkout fql
dev005:~/www-git$ git rebase master
<works normally, lots of output spew>
dev005:~/www-git$ git checkout fql-new
dev005:~/www-git$ git rebase master
First, rewinding head to replay your work on top of it...
HEAD is now at a5074e5... Fix IE6 display bug on photo_comments
*********
at this point I think to myself "oops, I meant to rebase to fql, not to
master" and press ctrl+c
*********
dev005:~/www-git$ git rebase fql
First, rewinding head to replay your work on top of it...
HEAD is now at 7b49c62... split up some fql/fields/ files to more closely
match the actual tables we have
Fast-forwarded fql-new to fql.
******
notice that it doesn't apply any changes on top of fql and doesn't output
any spew here
*******
dev005:~/www-git$

and just like that, now all those changes from fql to fql-new are totally
lost.  git log and git show-branch show no trace of them.

Re: Recovering from an aborted git-rebase?

[Shawn O. Pearce]

Steven Grimm <koreth@midwinter.com> wrote:
> Got this from one of the other people here who's using git. Luckily he 
> was able to restore his repo from a filesystem snapshot, so no permanent 
> harm done, but what's the pure-git way to recover from this? Are the 
> revisions in question really gone?

Try `git lost-found` before you use `git prune` (or also now `git gc`).

Also, if you have relogs enabled on your work branches (and I hope
you do, as its now the default) you can look at the branch from
earlier, e.g.:

	git log HEAD@{5.minutes.ago}
or
	git log HEAD@{1}

to look at HEAD was just before `git rebase` did the reset.  Which
would be the commit you lost, but want back.


Unfortunately we don't really have a reflog viewing utility yet so
you just have to sort of guess around with the @{...} syntax to find
what you are looking for.  But if you can locate the correct SHA1
for the last commit you want back you can do a `git reset --hard $sha1`
to restore your working branch, then do the rebase the way you meant to.
 
-- 
Shawn.

Re: Recovering from an aborted git-rebase?

[Junio C Hamano]

Steven Grimm <koreth@midwinter.com> writes:

> dev005:~/www-git$ git rebase master
> First, rewinding head to replay your work on top of it...
> HEAD is now at a5074e5... Fix IE6 display bug on photo_comments
> *********
> at this point I think to myself "oops, I meant to rebase to fql, not to
> master" and press ctrl+c
> *********

Doesn't "git rebase --abort" work for you at this point?

Re: Recovering from an aborted git-rebase?

[Steven Grimm]

Junio C Hamano wrote:
 > Doesn't "git rebase --abort" work for you at this point?

It probably would have, but he ran another "git rebase" immediately 
after hitting ctrl-C, not realizing that the interrupted one had left 
things in an odd state. I tried --abort after the fact and it said there 
was no rebase in progress; I assume the second rebase wiped out the 
temporary state from the first one.

However, all's well; Shawn's suggestion of using the reflog worked fine. 
We were able to reset back to HEAD@{3 hours ago} then do the rebase 
again, and it did the right thing. Even though we had a filesystem 
snapshot to fall back on, needless to say we were very happy to see 
there was a way to recover using nothing but git commands.

Hooray for the reflog being turned on by default!

-Steve