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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 16, 2009, 12:10 UTC
Message-ID: <alpine.DEB.1.00.0901161305520.3586@pacific.mpi-cbg.de>
In-Reply-To: <7v3afkqcnt.fsf@gitster.siamese.dyndns.org>

Hi,

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

Show 16 quoted lines

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