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

SZEDER Gábor [off-list ref] writes:

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

Hi,

On Thu, 15 Jan 2009, Junio C Hamano wrote:

 (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?

AFAICT the special handling is the only sane way to cope with (2) and (3), 
if it is the special handling that I am talking about:

If the current HEAD differs with the HEAD just after dropping to the 
shell, rebase --continue will _not_ just commit with the recorded 
information and continue.

The intended effect is that when you split a commit and continue with 
uncommitted changes, it will not just go ahead and call an editor with the 
original commit message: this message is now likely wrong.

It will only call an editor with the original message as a convenience 
when you did changes, but did not commit at all before continuing.  Just a 
convenience I found quite useful.

Ciao,
Dscho