Re: collapsing commits with rebase

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Jan 8, 2009, 04:09 UTC
Message-ID: <slrngmav3b.20e.sitaramc@sitaramc.homelinux.net>
In-Reply-To: <200901072011.37299.bss@iguanasuicide.net>

On 2009-01-08, Boyd Stephen Smith Jr. <bss@iguanasuicide.net> wrote:

>>    A---B---C---D---E---F

> Assuming you also have a ref (e.g. Foo) that points to F:
> git checkout sha(B)
> git merge -s sha(D)

I think you now need to do a commit (assuming you meant "--squash"). Squash will not commit, and your rebase below (if it runs at all -- I suspect it will refuse to run) will hard reset to B, the current HEAD. IOW

> After the merge:
> A -> B -> C -> D -> E -> F [Foo]
>      |
>      +--> [HEAD]

is not true.  You have C+D in the index, not in the tree.

> git rebase --onto $(cat .git/HEAD) sha(E) Foo

Also I think you have an off-by-one error here; you need sha(D) in that rebase command, not sha(E).

As your rebase command stands, you will lose commit E completely; neither the merge nor the rebase will pick it up.

[Haven't tested, but I *think* I understand rebase well enough now to say so...]