Git Rebase seems to have worked but all commits are still showing in the log... what state am I in?

Question

I think I squashed the last 40 commits using rebase. I was following this guide to make sure I didn't do anything stupid - http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

The problem is, I think I did something stupid.

The (interactive) text file couldn't be saved, so it seems that the rebase failed but the message it gave and some other things below suggest it might have worked.

Not sure where I am or what to do (or even what my name is). Here's what I did:

• I typed git rebase -i HEAD~40
• A text file came up, which I edited, by changing all lines to start with 'squash' except the top one
• I'm on windows, using EditPad... the file can't be saved! Oh noes... (read-only/permissions?).
• I save it to a random directory.

• The command line shows some sort of success (unfortunately I've lost the message). I don't know how it could succeed or know where the file I saved is...

• git rebase --continue says "No rebase in progress?

• git reflog suggests it worked (from what I know at least, the word 'rebase' is showing on the last 40 odd commits) eg:

  9992445 HEAD@{8}: rebase: reports working

• but running git log shows all 40 commits I just 'rebased'

This isn't looking good. Does anyone know what state I'm in? Am I in limbo, was this a zombie rebase?

Jennie

do you have other branches pointing to your rebased commits? – Escort

Answer 1

If the rebase "todo list" couldn't be saved, your rebase didn't work.

The easiest way to squash that many commits would be to do git reset --soft HEAD~40 and then git commit with your new message - assuming you want to squash all of them.

Febrific

Thanks, this is a neat solution (I forgot to ask for tips/solutions but you've given it) – Jennie

This solution works, as it's what I ended up doing to fix the situation – Jennie

Answer 2

This question is about a slightly surprising aspect of the behaviour of git rebase -i. If you close the editor window without making any changes, then the rebase still takes place.¹ (This is very different from the action when the editor for commit messages is popped up, where exiting your editor without making any changes aborts the commit.)

In your case, since you saved the interactive rebase list elsewhere, and then exited the editor, git assumed that you just want to reapply all those commits as before - it has no way of telling that you saved the file elsewhere. If the history was linear between HEAD and HEAD~40 then the history will be exactly the same (including the object names of each commit), but if it was non-linear you will have rewritten your history so that it's linear (and so will have different object names for some of the commits).

You might want to check in the reflog that HEAD has the same object name (hash) before and after the rebase to check this.

¹ Although in the version I'm using, if git can tell that the result would be exactly the same it doesn't bother to actually reapply the commits and just puts a single entry in the reflog. However, that optimization clearly hasn't taken place in your situation, since you can see the reapplication of each commit in the reflog.

Bleeder

Thanks, that's the sort of explanation I was hoping for – Jennie