Bug report: `git revert` on empty commit fails silently

Alistair Lynn· Jun 18, 2015, 15:27 UTC · lore

Hello gitters

Steps to reproduce:

$ git commit --allow-empty -m ‘test’ $ git revert HEAD

The latter fails silently, leaving HEAD pointing at the commit created by the first command.

A subsequent `git commit --allow-empty` has the revert message as the default commit message when starting the editor.

Hope this is the right place for bugs.

Alistair

Junio C Hamano· Jun 19, 2015, 05:05 UTC · re: Alistair Lynn · lore

Re: Bug report: `git revert` on empty commit fails silently

Alistair Lynn <alistair@othernation.com> writes:

Show 5 quoted lines

> $ git commit --allow-empty -m ‘test’
> $ git revert HEAD
>
> The latter fails silently, leaving HEAD pointing at the commit created
> by the first command.

I do not necessarily think it is a bug to ignore reverting a no-op. "revert a no-op" should probably fail by default, and the command should require --force or --allow-empty.

But I agree that silently ignoring is not good. It should warn the user, saying that reverting no-op is nonsense, when refusing the request.

> A subsequent `git commit --allow-empty` has the revert message as the
> default commit message when starting the editor.

And leaving a populated MERGE_MSG file to be picked up by the next commit, which is an unrelated operation, is clearly wrong, I would think. If we deem the "revert a no-op" as a nonsense and ignore it, we should ignore it completely and should not leave MERGE_MSG.

But leaving MERGE_MSG is internally consistent, I think. When "revert" stops due to conflicts and returns the control to the user, it would explain the situation to the user loudly, and then after user helps Git by resolving the conflict, the user uses "commit", and the message is picked up from MERGE_MSG. I'd view what you saw very similar to that situation. Instead of seeing a conflict (with which the command cannot automatically continue), the command saw a "no-op" (which it is dubious that the user really meant to revert). Asking the user to help and then allowing the user to signal that s/he is now done with "git commit" is the right way to continue, and for that to work seamlessly, the message has to be in MERGE_MSG.

So perhaps the only buggy part of this whole experience is that the command "silently" failed, instead of explaining the situation (i.e. "No changes to revert"); in case the user still does want to commit the revert of no-op by "commit --allow-empty", it did the right thing by leaving the message in MERGE_MSG to be picked up later.

I dunno.

> Hope this is the right place for bugs.

Yes, this is the right place for bugs.

Thanks.