
Honey I Squashed the Commits - denniskubes
http://denniskubes.com/2012/08/22/honey-i-squashed-the-commits/
======
latchkey
In summary, use cherry-pick to apply specific commit diff's (by hash) to a new
branch. Makes perfect sense. I also use this technique all the time with
github projects where I just want a bug fix or two from someone else's fork.

~~~
lloeki
You don't even have to cherry-pick. Use git reflog to find the topmost correct
sha1 (or in the example, right after the rebase, HEAD@{4}), and then do

    
    
        git checkout -b revovery
        git reset --hard HEAD@{5} #(the checkout made HEAD change, hence +1)
    

or even faster:

    
    
        git branch recovery -f HEAD@{4}
    

The key here is to understand that git commit objects include a reference to
their parents, and that git merely constructs a branch's history by evaluating
the ref to a sha1 and walking over objects recursively. So to recover we
merely make something point at the topmost sha1.

Then, in the case of additional commits that came _after_ the squash, you use
_git rebase --onto_ to replay the commits that came after the squash on top of
the unsquashed commits, which would give us:

    
    
       git checkout -b recovery
       git rebase --onto last_sha1_before_squash squashed_commit_sha1 recovery
    

The _checkout -b_ is just so that rebase will handily move that pointer for us
(see _man git-rebase_ ) while _rebase_ will replay commits from
_squashed_commit_sha1_ 's child up to the commit currently pointed at by
_recovery_ , over _last_sha1_before_squash_ (again, see man page)

~~~
latchkey
Nice! Thanks for the explanation.

------
natedub
Recovering seemingly lost commits is really important skill to have when
working with git. However, it is infinitely easier with the git reflog
command.

~~~
denniskubes
I have updated the article to show both the git reflog and using the HEAD
file.

