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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux