On 2024-05-17 09:32, Patrick Steinhardt wrote:
On Fri, May 17, 2024 at 12:09:54AM -0700, Junio C Hamano wrote:
Sean Allred <allred.sean@xxxxxxxxx> 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).
I quite frequently use "edit" just to inspect commits, stop at random
points in the history, run tests and whatnot. So this would be a UX
regression for me because I do not want to change commit messages and
don't want to be bothered.
With the introduction of the "break" command you can certainly argue
that "edit" is the wrong command to use in my case. Muscle memory is
hard to retrain though :)
One could potentially make the behaviour configurable so that you get
to
choose how "edit" behaves.
I agree that it would be best to introduce a new configuration option
for this purpose. Making such a change in the behavior of interactive
rebase permanently would probably result in more than a few raised
eyebrows, while a new configuration option would be a safe choice.
