Re: Q: howto rebase

[Jeff King <peff@peff.net>]

On Tue, Sep 25, 2007 at 04:46:59PM +0200, lode leroy wrote:

> In "version B" I introduce the "fix c", but in "version D" I realize it 
> should have
> been in some other place. (commit D moves the fix to its proper place).
> A-B-C-D-E
>
> Now I want to 'rewrite history'.
> I would like to move commit D after B
> A-B-D'-C'-E
>
> and then fold the commits B and D' into a single commit.
> A-B'-C'-E
>
> I somehow managed to get this done using "rebase -i"
> by exchanging the 2 appropriate lines, and then deleting the second one,
> but I'd like to understand how to do this from the command line...

The essence of git rebase is "move these commits as if they had happened
off of a different base commit." The interactive mode of rebase is
considerably more powerful, in that it allows squashing, deleting, and
arbitrary reordering. To do solve your problem without using "rebase
-i", you could do this:

# make a new branch based on 'B', which is where we want to base our commits
git-checkout -b tmp B
# pick the changes from 'D', but don't commit
git-cherry-pick -n D
# redo 'B' with the new changes
git-commit --amend

now you have a graph like this:

A-B-C-D-E
 \
  \-B' <-- branch tip

so you need to rebase C-D-E on top of it (and rebase will realize that
'D' has already been applied), with:

  git-rebase --onto tmp B master

Converting this to the manpage terminology, "B" is your upstream, and
you want to grab all of the changes from "B" to your "master", but you
want to put them on the newly created B'. Which perhaps is a little
confusing, but that's because git-rebase was designed for a simpler
situation: you and some upstream repo both made commits that the other
doesn't have, and you want to pretend your work is based off of their
most recent version.

You can see that "rebase -i" is a lot more flexible for these sorts of
history re-writing schemes. If you really must do it without user
interaction, I suspect you could use a sed script as your $GIT_EDITOR.

-Peff