Victor Toni <victor.toni@xxxxxxxxx> writes:
> When doing a commit or choosing what to do for an interactive rebase
> one can just wipe the whole content of the editor, save and close to
> abort the action.
> While doing a `git rebase --edit-todo` I came to the conclusion that I
> would like to abort the edit and did the same. The final `git rebase
> --continue` got me rid of the rest of the commits...
> (Fortunately the "missing" commits could be rescued by looking into
> `.git/logs/HEAD` so thumbs up for that. )
> Unfortunately the behaviour of `--edit-todo` was a bit surprising and
> somehow doesn't feel consistent with the other actions involving an
> editor.
>
> Can this be considered a bug?
It is rather unusual (or almost always wrong) to have a totally
empty commit log or initial todo list, so it is understandable for
Git in these situations to stop without doing anything further.
There is no other sensible interpretations of what you are telling
Git to you by returning an empty buffer---it is extremely unlikely
you want to create a commit with no log message (without explicitly
allowing it with --allow-empty-message, the command is likely to
fail anyway), and it is extremely unlikely that you wanted to just
reset the tip of the branch to the --onto commit.
Once an interactive rebase session has started and you are given the
remainder of the steps to edit and you give an empty buffer back,
however, there are two possible interpretations that are equally
sensible, I would think.
- One is that you are signaling that you are done with the rebase
session and all the remaining commits are to be discarded.
- The other is that you botched editing the todo list, and you wish
Git to give you another chance to edit it again.
I think the implementor chose the first interpretation. The "drop"
insn is a relatively recent invention, and back when it was missing
from the vocabulary, I do not think it was possible to say " discard
all the rest" without emptying the todo list, so that design is
understandable.
Now we have the "drop" verb, the latter interpretation becomes
possible without making it impossible for the user to express the
former. It might be a good idea to
(1) save away the original before allowing --edit-todo to edit,
(2) open the editor, and
(3) when getting an empty buffer back, go back to step (2) using
the back-up made in step (1).
Either way, the todo list editor buffer can have additional comment
instructing what happens when the buffer is emptied.
I have no strong opinion on this one myself. Deferring to Dscho,
who may have a lot more to say on the design issue around this
feature than I do.
Thanks.
