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

From: Sean Allred <allred.sean@gmail.com>
Date: May 16, 2024, 22:18 UTC
Message-ID: <m0seyhs8o2.fsf@epic96565.epic.com>
In-Reply-To: <xmqqy189o94c.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

> I personally found this a bit unintuitive, because in my metal
> model, "reword" is a mere subset of "edit": the latter would give me
> chances to change both the contents and the log, while the former
> only would offer me a chance to change the log.

My mental model is not quite the same, interestingly: 'reword' and 'edit' are not-quite-orthogonal, not-quite-parallel in terms of intent. In 'reword', I know that I just care about the log. In 'edit', I don't know *what* I'm going to do -- in fact, my mental model is more friendly to the idea that 'edit' => 'pick then break'. This of course may be a mental model learned from the observed behavior and not conceived from the ideal behavior.

My 2c: in the case where you're changing the tree, you will already be prompted to change the log. It appears the assumption is that if you do not change tree, you will not need to change the log.

This assumption holds true for me, but my workflow is generally to get each commit's patches into the desired state and only *then* spend some quality time with my messages. That's certainly not the only workflow, though.

> After all, the reason why it may become necessary to edit the log is
> because the user made some changes to the tree in the first place. And
> by not opening the editor, only to close it without making any change,
> the command is saving the user some keystrokes.

...and you seem to be on the same lines of thinking as I am. Playing devil's advocate a bit: there are certainly other cases in Git where the editor pops open and I have muscle memory to close it. I wish I could recall in this moment where those cases were, but I don't know that avoiding an invocation of the editor is a good reason not to invoke the editor if that's the Right(tm) thing to do -- that seems to be a circular argument.

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.

-Sean

-- 
Sean Allred