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

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