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. Patrick
Attachment:
signature.asc
Description: PGP signature
