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.
