threads / discuss / 6320

Recovering from an aborted git-rebase?

Subject: Recovering from an aborted git-rebase?

## tl;dr

4 messages between Jan 9, 2007 and Jan 10, 2007.

replies: 3people: 3as markdown or json

Steven Grimm· Jan 9, 2007, 23:20 UTC · lore

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.

Shawn O. Pearce· Jan 9, 2007, 23:29 UTC · re: Steven Grimm · lore

Re: Recovering from an aborted git-rebase?

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.
Junio C Hamano· Jan 10, 2007, 00:25 UTC · re: Steven Grimm · lore

Re: Recovering from an aborted git-rebase?

Steven Grimm <koreth@midwinter.com> writes:
Show 7 quoted lines
> 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?
Steven Grimm· Jan 10, 2007, 18:53 UTC · re: Junio C Hamano · lore

Re: Recovering from an aborted git-rebase?

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

← back to recent threads