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

From: Junio C Hamano <gitster@pobox.com>
Date: May 17, 2024, 07:09 UTC
Message-ID: <xmqqmsoonccd.fsf@gitster.g>
In-Reply-To: <m0seyhs8o2.fsf@epic96565.epic.com>

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

Show 9 quoted lines

> 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).