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

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

[Alistair Lynn]

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

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

[Junio C Hamano]

Alistair Lynn <alistair@othernation.com> writes:

> $ 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.