From: Junio C Hamano <gitster@pobox.com>
To: Alistair Lynn <alistair@othernation.com>
Cc: git@vger.kernel.org
Subject: Re: Bug report: `git revert` on empty commit fails silently
Date: Thu, 18 Jun 2015 22:05:20 -0700 [thread overview]
Message-ID: <xmqqioakb84v.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <A18BC2A3-C9A6-4D03-B929-D821E90B812D@othernation.com> (Alistair Lynn's message of "Thu, 18 Jun 2015 16:27:41 +0100")
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.
prev parent reply other threads:[~2015-06-19 5:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 15:27 Bug report: `git revert` on empty commit fails silently Alistair Lynn
2015-06-19 5:05 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqioakb84v.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=alistair@othernation.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.