[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:       Junio C Hamano <gitster () pobox ! com>
Date:       2009-01-16 1:09:58
Message-ID: 7v3afkqcnt.fsf () gitster ! siamese ! dyndns ! org
[Download RAW message or body]

SZEDER Gábor <szeder@ira.uka.de> 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".
--
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]