Re: Help rescuing a repository

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

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