collapsing commits with rebase

Dear gits,

I have a series of commits:

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

I want to collapse B---C---D into one single commit. git rebase -i B will allow me to do this, but I'm looking for a non-interactive incantation.

Cheers, Geoff Russell

P.S. The context is a program that performs a single high level operation on a repository as a series of commits but then wants to turn it back into a single commit without user intervention so it subsequently looks like a single op in the history.

Hi,

On Thu, 8 Jan 2009, Geoff Russell wrote:

You set GIT_EDITOR to a script ;-)

Alternatively, something like this should work for you:

	$ git checkout A
	$ git read-tree -u -m D
	$ git commit -m "My message"
	$ git cherry-pick E
	$ git cherry-pick F

Hth, Dscho

On Thu, Jan 8, 2009 at 11:15 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

This is plan B.

Plan B is looking good, because I'd generally like the commit message to be the concatenation of the messages for B,C and D.

Many thanks.

Geoff.

Hi,

On Thu, 8 Jan 2009, Geoff Russell wrote:

Replace the commit call by this:

	$ for commit in B C D
	  do
		git cat-file commit $commit | sed '1,/^$/d'
		# possibly add an empty line between the commit messages,
		# git commit will strip away empty lines at the end.
	  done |
	  git commit -F -

Hth, Dscho

On 1/8/09, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

That makes sense, many thanks.

Cheers, Geoff.

On Wednesday 2009 January 07 18:08:44 Geoff Russell wrote:

Assuming you also have a ref (e.g. Foo) that points to F: git checkout sha(B) git merge -s sha(D) git rebase --onto $(cat .git/HEAD) sha(E) Foo

should do what you want.

After the checkout: A -> B [HEAD] -> C -> D -> E -> F [Foo] (detached HEAD)

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

After the rebase:
A -> B -> E' -> F' [Foo, HEAD]
     |
     +--> C -> D -> E -> F
(C, D, E, and F will be pruned at some point)

On Wed, Jan 07, 2009 at 08:11:32PM -0600, "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:

You probably mean --squash here, -s stands for --strategy - and I *hope* you don't have git-sha(D) in your PATH, as a custom merge strategy. ;-)

On Wednesday 2009 January 07 20:32:24 Miklos Vajna wrote:

<bss@iguanasuicide.net> wrote:

Oops.  Yes.  My mistake.

On 1/8/09, Boyd Stephen Smith Jr. <bss@iguanasuicide.net> wrote:

Many thanks, now I have plenty of ways to think about!

Cheers, Geoff.

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

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

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

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

On Wednesday 2009 January 07 22:09:15 Sitaram Chamarty wrote:

Probably understand it better than me. I just haven't needed to use it for this that much. This also might not be much better than setting GIT_PAGER to a script, but it seems less fragile to me.

On Thursday 08 January 2009 01.08.44 Geoff Russell wrote:

Hi Geoff, Could you please share with use the final (tested) solution? I'd be interrested to see how you did implement plan B if you did.

Cheers, Nadim.