[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC PATCH] Make the rebase edit mode really end up in an edit
From:       Johannes Schindelin <Johannes.Schindelin () gmx ! de>
Date:       2009-01-16 12:10:58
Message-ID: alpine.DEB.1.00.0901161305520.3586 () pacific ! mpi-cbg ! de
[Download RAW message or body]

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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]