On 2024-05-16 15:21, Junio C Hamano wrote:
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.
It's been this way forever (or close enough; I've been using Git since ~2010).
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.
My mental model has always been that "edit" means "amend" -- when I tell "git rebase" I want to "edit" a commit it (usually) means I intend to "git commit --amend" it in some fashion, whether that's to update the tree the commit changes, or to tweak the message, or both. (Or something else entirely -- since I'm at the shell prompt, I can do anything! The power!)
I like that "edit" does not open the editor if I decide not to change any files, but does open it if I do change any files (and that "git rebase" does the amending for me if I just stage the changes and say "git rebase --continue"). Seeing the editor after I say "git rebase --continue" is also a good reminder to me that I've changed something in the tree being committed. I've found this helpful if I've been distracted during a rebase session.
If I *know* that I only want to edit the message, then I say "reword".
Of course, we can work it around with "git rebase --edit-todo" before saying "git rebase --continue".
Or, more directly, just "git commit --amend".
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.
Yes, and I've always appreciated this behaviour. M.
But given that saying "edit" and not making any changes is a rare case, it feels wrong thing to optimize for. Anyway.
