Help rescuing a repository

Help rescuing a repository

[Luke Lu]

I was doing some git rebase -i in a topic branch (topic/ser) to squash  
and reorder some commits. There were some conflicts. I fixed the  
conflicts and typed git rebase --continue. The cycle continued a few  
times and then this happened:

  13 files changed, 68 insertions(+), 41 deletions(-)
error: Ref refs/heads/topic/ser is at  
5cfb6b694f2d5a1ff429fe86f6c5ecafed159e47 but expected  
a10a7127be3441c732cab5baa2dd8684591f91f7
fatal: Cannot lock the ref 'refs/heads/topic/ser'.

$ git status
# Not currently on any branch.
nothing to commit (working directory clean)

$ git fsck
dangling blob 8861482c7e1731be2436f75ae6276d0f9c4833e0
dangling blob 94c1b94b5146b58cda4ee50854241b192f701bea
dangling blob 01a2371e749ab7e14707cfb4d3846035fcaee728
dangling blob 4ca2b920849a1517a46279c4b56896fd79625a6c
dangling blob 56e32abf19627dcf79ee123bae9ddb08423bc5ba
dangling blob 73832cd404915d7bc5e0aac1e87fa3bb64293531
dangling tree 73c34a56d1da91d4ea606055d558ef290949fb70
dangling blob b5c3dfefd345e8296e56518b7e537d9e20814288
dangling blob c743999c4762380d3d318ae7b80bba32d4bc4f53
dangling tree 1184c889e044163dd857f3858c09970080720993
dangling blob eca57f10d1dc19dc4bb3dba2c08e393c1e31832b
dangling blob f5a5b7e5e922412ebeabdbc52ecc3354298e3690
dangling blob 47064db7a58b95d02885e5c3004b7920a0dc534f
dangling blob 4966a6f65c912418b33b13fe6f10fb368c2545cf
dangling commit 75c6f9bb9d093390d260819f80cd94fc20849d30
dangling blob bd4752468dbb11274285184cb0c602a2cd259eb5
dangling blob c8074b20ded0a36ff07df5595116442af5515498
dangling tree 0848c028fc28008de1a845c9524e3ab12df9832b
dangling blob 7ec9928b3c0db7ec737fa70b4bb9615b068ee990
dangling blob b44967adc33ec1ddcba49f75cd55127facbb7a00
dangling blob 23ca6b90505dae2607af6415e3ccc038daf0109d
dangling blob b58aac43a313abf6ac21754ec258caeb388a16f6
dangling blob eeebecd8db7d263f77e132b2e82ac4864775b61c
dangling blob 3e0c62d3e778bef1a0f17379ba2a3731da629fce
dangling blob 20cd6eab485de1b0d412cf16e41e88b92ab7e977
dangling blob 8b6d1ba9efb6de596a77aa4be6a36db3d2c6687c
dangling blob b58de59a60c002f99c6ef2463f1678106f07da7d
dangling blob 2fae8d768ac0ae872f513566334d9b4134cf1e28
dangling blob 33ee2202ded44151efb066bc567845b259ce7217
dangling blob afae3fef0b92b14acf7fb1c3e511561111986de5
dangling blob 3f6fd047ac02f1ec7694fd906c762320ed148532
dangling blob 85afb26ca1d651e1745537c60fda5a1807048cb4
dangling blob a30f3e844d6eba2f23ed91470962f12ffebaf0cf
dangling blob bdafe70378182035702a41a7f8854e9f3eaef7dd
dangling blob e96fd7d00b6c05a48477f64ce0085f1fa40207a1
dangling blob 2390ce4ff58008ac1fd3b54dae31116ff4dbbbae
dangling blob 4ab0f1a55f987f1c2e06406199b96ce2e7388bcb
dangling blob 75b0f4cc59aa4a3ae9ac1fa01fbb6383d6584aac
dangling blob 9b7035d40c61259563470a2ea42c2943aec443d0
dangling blob 1752370b44a133f1519ffef5452f772cef99c93f
dangling blob 10b316e7f25212e66e1213dc1303b03339bf6648
dangling blob 883397ee9b21724e03547e7ca71c60e87cd7bbfa
dangling tree 8f135a32c77825713ec70b7367d1134b9dc15006
dangling tree 91f394d3e2566f703434ba3a6b3021496d1167ef
dangling blob 2374b17b997a232835ad817c1173a5bd1e34d30b
dangling blob 8894bb0e8dad66c3cf57350e36252a2f1746a6fb
dangling blob 20b522551d824bfd83685f391d490308dae7c3e1
dangling blob 8cb6086ec13a97a88b9530983f4b4dd77905615f
dangling blob a997eaf05db866b0108e9c754129418237384aed
dangling tree 6118e30cbefd3fe26c51fce8595674a55ff24279
dangling blob 88d9b06bc81abd155604c8ef6b595042bc955d45
dangling blob dfd925e457eb9295587029dca7ce1060f7cc030c
dangling blob c3fbac839f7e35c208110cfab9c0d95eae3f488b
dangling blob 34bce1a591d9bf67bab966a9a9cfeff5e3723d11
dangling blob 9f5c4d0b8bd5e169d1c36658dfd8b1d508641093
dangling blob 1fdda77640dd0d0bf48fe4ee88ab823cb004d8fa
dangling blob 495d6c267d62f82a5a4f0d6c75d111cebcdb3f29
dangling blob c87df955d86c2c13ca45b90ac9a598ba901ba06e
dangling blob 20dee3523801fa85182d2159d4f6ad2fe5c56bad
dangling blob 3f1ea7888bf98019df10c4e5aa6b22cd65daf8d1
dangling blob 8d5ef43998cb64575c4902ac7855d394b5f9d326
dangling blob 121f865528655c03cfbb10d0c29dda678666eb8e
dangling blob badfc40fabb32650ccbb33456766e9d58588f8ed
dangling commit d2bf234e4b0735695a59836f04b4f1558ebacfdc
dangling blob f3df2aebbbd0b00dc8210b6c51806d7f4fd409ef

I've used git rebase -i before without any problem. The only  
difference this time is that there are more commits (50+) and more  
files (hundreds) and changes (thousands) involved due to some global  
find & replace. I *might* have committed something in the same branch,  
while the git rebase -i editor window is open (there are a lot of  
commits to reorder and squash, so I used another window to look at the  
commits I'm not sure about. I might have done a quick fix (likely  
whitespace errors :) and committed)

$ git --version
git version 1.5.5.1

I have the gut feeling that it might be fixable by some magical  
incantation to connect the refs to my branch. But I don't know git  
internal very well. I need your help. My work obviously depend upon it.

Thanks in advance!

Re: Help rescuing a repository

[Linus Torvalds]

On Tue, 10 Jun 2008, Luke Lu wrote:
>
> I was doing some git rebase -i in a topic branch (topic/ser) to squash and
> reorder some commits. There were some conflicts. I fixed the conflicts and
> typed git rebase --continue. The cycle continued a few times and then this
> happened:
> 
> 13 files changed, 68 insertions(+), 41 deletions(-)
> error: Ref refs/heads/topic/ser is at 5cfb6b694f2d5a1ff429fe86f6c5ecafed159e47
> but expected a10a7127be3441c732cab5baa2dd8684591f91f7
> fatal: Cannot lock the ref 'refs/heads/topic/ser'.

Ok, you seem to have committed something in another session (other window 
or something) at the same time as doing that git rebase series. As a 
result, the rebasing commit was unhappy, because you basically ripped the 
rug out from under it by changing the branch it was working on.

> $ git status
> # Not currently on any branch.
> nothing to commit (working directory clean)

Don't worry. Nothing has gone away, although you may now need to *find* 
the particular branch tip(s) that you are interested in.

> I've used git rebase -i before without any problem. The only difference this
> time is that there are more commits (50+) and more files (hundreds) and
> changes (thousands) involved due to some global find & replace.

That shouldn't matter, except that it was obviously very likely one of the 
reasons for the conflicts too.

What mattered is:

> I *might* have committed something in the same branch, while the git 
> rebase -i editor window is open (there are a lot of commits to reorder 
> and squash, so I used another window to look at the commits I'm not sure 
> about. I might have done a quick fix (likely whitespace errors :) and 
> committed)

Yup, that would explain it.

> I have the gut feeling that it might be fixable by some magical incantation to
> connect the refs to my branch. But I don't know git internal very well. I need
> your help. My work obviously depend upon it.

Most likely, the only thing you actually need to do is simply

	git rebase --abort

and it will just take you back to the state you were in before the rebase, 
and now you'll have to redo it all.

BUT. You can also decide that instead of doing that, you want to keep the 
work you did do, and just try to continue. You'll just need to figure out 
where you are, and where the rest of the commits you want to do are.

And those things should not be so hard to figure out, at least if you 
still have a reasonably good idea about what the commits were that you 
cared about. You just need to find all the relevant development tips, and 
it turns out that that is actually mostly pretty easy.

You have one right there: the current disconnected HEAD you are on is one 
tip. You can save that one away by making that a real branch, so you don't 
lose it, with something like

	git branch middle-of-rebase

which will just take your current state, and make it the new branch 
'middle-of-rebase'.

You can also try to get a better view of where you are by doing

	gitk --all

to show all the branches graphically, which is usually a great way to get 
your bearings. Keep the gitk window open in the background as a reference.

After that, do

	git log -g

wher the "-g" (or "--walk-reflogs" for the long version) just means that 
instead of looking through history as a chain of commits and their 
parents, you look through not the chain of commits, but as the chain of 
reflog entries (which are basically about how the HEAD has changed due to 
the commands you have done).

In all of that info, look for the place you want to go back to, and just 
start all over from there. You can either re-use one of your old branches 
and just start over from some state that you want:

	git checkout <branch>
	git reset --hard <startingpoint>

or you can decide that you want to start a new branch to fix up the mess 

	git checkout -b <newbranch> <startingpoint>

and only when it's all fixed up and you're happy will you change any of 
your old branches.

But it may well be that "git rebase --abort" and re-doing everything is
the least confusing option.

			Linus

Re: Help rescuing a repository

[Luke Lu]

On Jun 10, 2008, at 7:08 PM, Linus Torvalds wrote:
>
> On Tue, 10 Jun 2008, Luke Lu wrote:
>>
>> I was doing some git rebase -i in a topic branch (topic/ser) to  
>> squash and
>> reorder some commits. There were some conflicts. I fixed the  
>> conflicts and
>> typed git rebase --continue. The cycle continued a few times and  
>> then this
>> happened:
>>
>> 13 files changed, 68 insertions(+), 41 deletions(-)
>> error: Ref refs/heads/topic/ser is at  
>> 5cfb6b694f2d5a1ff429fe86f6c5ecafed159e47
>> but expected a10a7127be3441c732cab5baa2dd8684591f91f7
>> fatal: Cannot lock the ref 'refs/heads/topic/ser'.
>
> Ok, you seem to have committed something in another session (other  
> window
> or something) at the same time as doing that git rebase series. As a
> result, the rebasing commit was unhappy, because you basically  
> ripped the
> rug out from under it by changing the branch it was working on.

So you've seen this problem before?

>> I *might* have committed something in the same branch, while the git
>> rebase -i editor window is open (there are a lot of commits to  
>> reorder
>> and squash, so I used another window to look at the commits I'm not  
>> sure
>> about. I might have done a quick fix (likely whitespace errors :) and
>> committed)
>
> Yup, that would explain it.
>
>> I have the gut feeling that it might be fixable by some magical  
>> incantation to
>> connect the refs to my branch. But I don't know git internal very  
>> well. I need
>> your help. My work obviously depend upon it.
>
> Most likely, the only thing you actually need to do is simply
>
> 	git rebase --abort
>
> and it will just take you back to the state you were in before the  
> rebase,
> and now you'll have to redo it all.

Before I thought of that, I just used the trusted git reflog to find  
the last commit I made before the rebase commits and did a git reset -- 
hard to that commit. It returned the tree to normal. Fortunately I  
have rerere enabled (by creating the .git/rr-cache directory, because  
I read your and Junio's posts on kernel trap). so I don't have to do  
much work to reedit the conflicts.

> BUT. You can also decide that instead of doing that, you want to  
> keep the
> work you did do, and just try to continue. You'll just need to  
> figure out
> where you are, and where the rest of the commits you want to do are.
>
> And those things should not be so hard to figure out, at least if you
> still have a reasonably good idea about what the commits were that you
> cared about. You just need to find all the relevant development  
> tips, and
> it turns out that that is actually mostly pretty easy.
>
> You have one right there: the current disconnected HEAD you are on  
> is one
> tip. You can save that one away by making that a real branch, so you  
> don't
> lose it, with something like
>
> 	git branch middle-of-rebase
>
> which will just take your current state, and make it the new branch
> 'middle-of-rebase'.
>
> You can also try to get a better view of where you are by doing
>
> 	gitk --all
>
> to show all the branches graphically, which is usually a great way  
> to get
> your bearings. Keep the gitk window open in the background as a  
> reference.
>
> After that, do
>
> 	git log -g
>
> wher the "-g" (or "--walk-reflogs" for the long version) just means  
> that
> instead of looking through history as a chain of commits and their
> parents, you look through not the chain of commits, but as the chain  
> of
> reflog entries (which are basically about how the HEAD has changed  
> due to
> the commands you have done).
>
> In all of that info, look for the place you want to go back to, and  
> just
> start all over from there. You can either re-use one of your old  
> branches
> and just start over from some state that you want:
>
> 	git checkout <branch>
> 	git reset --hard <startingpoint>
>
> or you can decide that you want to start a new branch to fix up the  
> mess
>
> 	git checkout -b <newbranch> <startingpoint>
>
> and only when it's all fixed up and you're happy will you change any  
> of
> your old branches.

I'm still not sure how to fixed it up and keep the merge results  
though. Just work on the tree (middle-of-rebase, which is actually the  
end of rebase, when it blowed up) until it's good and reset --hard my  
branch to it?

> But it may well be that "git rebase --abort" and re-doing everything  
> is
> the least confusing option.


git rebase --abort, I think, would actually blow away my last commit  
(I sneaked in) though. git reset --hard to that last commit is  
probably the right thing to do. The least confusing option would be to  
update the error message to be a bit more informative, like "Did you  
change the branch while rebasing? git reset --hard to your last known  
commit and redo the rebase". Yet another safeguard would be for git  
commit to check if there is a rebase in progress and warn or abort the  
commit.

Anyway, thanks for the informative reply. I have more confidence in  
git due to this accident :)

__Luke

Re: Help rescuing a repository

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1087 bytes --]

On Wed, Jun 11, 2008 at 05:04:25AM +0000, Luke Lu wrote:
> git rebase --abort, I think, would actually blow away my last commit (I 
> sneaked in) though. git reset --hard to that last commit is probably the 
> right thing to do. The least confusing option would be to update the 
> error message to be a bit more informative, like "Did you change the 
> branch while rebasing? git reset --hard to your last known commit and 
> redo the rebase". Yet another safeguard would be for git commit to check 
> if there is a rebase in progress and warn or abort the commit.

  OTOH the commit you did has been your HEAD for a moment, so it's
easily cherry-pickable from your reflog. So I'd go for the git rebase
--abort route, redo the rebase, and once done, then run git reflog and
find the commit that you want to get back, and cherry-pick it with its
proper reflog name: git cherry-pick HEAD@{nnn}.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]