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

[Junio C Hamano <gitster@pobox.com>]

What should happen when I turn "pick" to "edit" in a "rebase -i"
session, check what got checked out in the working tree, find it
satisfactory and decide not to make any change to the files, and say
"rebase --continue"?

The current implementation seems to just move to the next step,
without offering a chance to edit the log message.  I do not know
offhand if this is something we changed recently, or if it has been
that way forever.

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.

But the actual behaviour does not match that mental model.  "edit"
is purely about editing the worktree files, and only if files (hence
the tree recorded) are modified, a chance to edit the log is offered
to adjust the message to what the new tree brings on top of the
parent commit.

Of course, we can work it around with "git rebase --edit-todo"
before saying "git rebase --continue".  But the current behaviour
somehow feels optimized for a wrong case.  Admittedly, it is logical
that it does not offer a chance to edit the log message if we did
not make any change to the working tree.  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.

But given that saying "edit" and not making any changes is a rare
case, it feels wrong thing to optimize for.

Anyway.