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

I think I squashed the last 40 commits using rebase.
I was following this guide to make sure I didn’t do anything stupid –

The problem is, I think I did something stupid.

  • Why isn't .gitignore ignoring .sass-cache?
  • git: rebase with bases untracked in git
  • Jenkins/Git: Build latest from branches + manual build from any commit
  • Using git over ssh won't pick up private key
  • Adding a folder content in Git
  • Working while waiting for pending PR
  • 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?

  • Git commit in terminal opens VIM, but can't get back to terminal
  • Locate file in git repo
  • How to amend the second newest commit
  • Git merge or git rebase?
  • git log: show second parent on the left
  • How to push bare repo branches to another remote?
  • 2 Solutions collect form web for “Git Rebase seems to have worked but all commits are still showing in the log… what state am I in?”

    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.

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

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

    Git Baby is a git and github fan, let's start git clone.