Re: [Q] rebase -i: turn "pick" to "edit", make no change, what should happen?

[Junio C Hamano <gitster@pobox.com>]

Sean Allred <allred.sean@gmail.com> writes:

> Setting aside the obvious reality that an actual change here could have
> pretty serious UX considerations for folks with muscle-memory, what in
> your opinion would be the right thing to do? Why? Are rebase commands
> 'shortcuts' or are they intended to be orthogonal? Do they have designed
> purposes?
>
> I'm wondering if you can tease out what the 'ideal' state looks like to
> you, then you can identify what if anything there is to be done about
> it.

Oh, it would be very simple.

If I say "edit", whether I made a tree change or not, I want to get
an editor when I said "rebase --continue".  If I say "reword", I
want to get an editor _without_ having a chance to muck with the
tree status.  That would be the "ideal" behaviour, iow, the "mental
model" is just "edit" gives the users a chance to edit both trees
(by first giving control back to a shell prompt) and the log message
(by opening the editor upon "--continue"), while "reword" is only
about the message so does not give shell prompt back to the user
(unless absolutely necessary, that is.  If the "reword" were to
conflict due to tree changes in earlier steps, it would need to give
control back to a shell prompt to ask the user's help to resolve the
conflict.  It is just that when there is no need to edit the tree
otherwise, that is skipped).