Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 16, 2009, 01:09 UTC
Message-ID: <7v3afkqcnt.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090115225912.GL9794@neumann>

SZEDER Gábor <szeder@ira.uka.de> writes:

Show 6 quoted lines

> But the current behaviour of the 'edit' rebase command gives you the
> possibility of adding further commits on top of the selected one
> (after you have edited that or left intact, doesn't matter).  To do
> that with this automatic 'reset --soft HEAD^' modification you would
> first need to 'git commit -c @{1}' to keep the selected commit before
> going on with adding further commits, which is not quite nice.

Yeah, I agree.

I think my confusion mostly came from perception, and the way the "edit" action is (not) explained.

What "edit" means is "pick this commit and then stop to give control back to the user. The user is free to muck with the history starting from the state after picking the named commit in any way, and --continue will carry on the rest of the insns from the state" [*1*]. Once I realize that, it becomes clear what it means to do any of the following when "edit" gives the control back to me:

 (1) commit --amend (with or without changing the tree and message); this
     is the originally intended usage.  Edit the commit the machinery just
     picked and let it continue.  The end result is as if you edited one
     commit in the sequence.

 (2) making completely unrelated commits on top of the state "edit" gave
     you; this inserts a new commit in the sequence.

 (3) first "reset HEAD^", commit selected parts of the difference in one
     commit, commit the reaminder in another commit; this splits the
     commit the machinery just picked into two.

By the way, "rebase --continue" codepath has extra code that does something magical when the index does not match the HEAD commit. I suspect what it does makes sense only in the originally intended usage sequence (i.e. "edit" stops, you want to do "commit --amend" and then "rebase --continue" but somehow you forgot to commit everything).

How well does that logic work when the user wanted to do (2) or (3) above, and happened to have the index unclean when s/he said "rebase --continue"? Does it do something nonsensical?

[Footnote]

*1* Explained the same way, "pick" is "cherry-pick the named commit to replay its effect and then continue".