On Jun 10, 2008, at 7:08 PM, Linus Torvalds wrote:
quoted text
>
> 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?

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

quoted text
> 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?

quoted text
> 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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html