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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
