Git rebase problems

OK; so I’m trying to squash my commits before pushing for code review/merge, but I keep running into problems.

Here’s a brief look at my git log (I have about 30 or so commits):

commit e1aa5e3ac4af3974be91203896997b0173ed4075
Author: Jonathan Seidel 
Date:   Thu Apr 3 07:03:29 2014 -0700

    Recover 'lost' commits... (16135/site)
    SDs lost through git rebase; unable to recover via git reflog (there; can't find them)
    Save file open in editing session and now all green.
    Same situation on lib (no rebase issues) & config (able to recover with get reset --hard).

commit a4fabca1deefb606487f977babc43056732288c5
Author: Jonathan Seidel 
Date:   Fri Mar 28 15:46:57 2014 -0700

    Final refactoring / cleanup; all green

commit 503d483fea3d135356959fef1616a059a260cddb
Author: Jonathan Seidel
Date:   Fri Mar 28 15:22:01 2014 -0700

    Refactoring, cleanup...
    Testing appears OK

commit 9d8eb1b8b43bf81cb4ac814afa5faab115bdafc8
Author: Jonathan Seidel 
Date:   Fri Mar 28 14:55:37 2014 -0700


And here’s the first part of the git rebase -i file:

pick 9dfb750 Last scenario working...
pick 3c230c9 Seveal scenarios passing...
pick 7d588bd Updates for SD on #15388...
pick 1594b0d Refactor FF & SD...
pick 1afafd6 Progress on #15388...
pick 5d85ff5 Google maps scenario passing...
pick 3694026 Updated code for review / bug isolation...

Couple of questions:

  1. Notice that the first item in the rebase pick list doesn’t match any commit in the git log

  2. When I change all but the first item to ‘squash’ and save the squash list, I get the following error:

    error: could not apply 9dfb750… Last scenario working…

I’ve tried using the --patch option and that seems to work – at least it gets further along – but I run into later problems wherein my branch got really messed up.

Any ideas as to what’s going on and how to resolve this? It’s driving me nuts and I can’t get my code merged.



I went looking for that 9dfb commit and finally found it via git reflogs:

9dfb750 HEAD@{745}: checkout: moving from review/jonathan.seidel/16167_bops_master_error_messaging to review/jonathan.seidel/15388_bops_item_availability

It’s 745 commits down the list and it’s a merge commit from when I pulled in master a ways back.


So I figured what the heck… I’ll just rebase back to that problematic commit:

git rebase -i 9dfb750

So it said showed 761 commits to be processed, I squashed all but the first one, it got through about 340 of them and then said:

error: could not apply 46749c4... Modify FF and create SD for story 16166

and I back where I started :=(


Took quite a while to to it, but I just followed the instructions that came with the error:

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.

Every time I hit a bump, do a git status, see where the issue is, and – in most cases – just skipped that particular commit. The last few commits were the ones where I’d worked on that particular story so could see more easily what to do.

Unfortunately, that didn’t work for git rebase origin/master – all my files simply disappeared when I went through the process. Good thing I had created a new branch :=)

1 Like

The commit hashes change every time you rebase as you are rewriting the tree. So not seeing commit hashes you think should be there is not surprising.

You need to squash your commits before you rebase against master. Squash often and in logical places, and rebase against master more than daily.

Thanks, @Dreamr… Yep, squash before trying to rebase against master is definitely the way to go; that’s exactly what I was trying to do

What I finally did was just checkout a completely new branch from master and then imported the files that I knew I had modified in the broken branch, and then ran all my tests to make sure things were working. I learned about the

git checkout <branch> <file>

command which makes importing files from another branch a piece of cake.