From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Thu, 08 Jan 2009 04:09:15 GMT
Subject: Re: collapsing commits with rebase
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...]