Recovering from an aborted git-rebase?

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.

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.

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