{"thread":{"id":"39671","subject":"Bug report: `git revert` on empty commit fails silently","startedAt":"2015-06-18T15:27:41Z","lastAt":"2015-06-19T05:05:20Z","messageCount":2,"participants":["Alistair Lynn","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"264188","messageId":"A18BC2A3-C9A6-4D03-B929-D821E90B812D@othernation.com","threadId":"39671","inReplyTo":null,"subject":"Bug report: `git revert` on empty commit fails silently","fromName":"Alistair Lynn","fromEmail":"alistair@othernation.com","sentAt":"2015-06-18T15:27:41Z","receivedAt":"2015-06-18T15:27:41Z","isPatch":false,"sender":{"key":"alistair@othernation.com","avatar":null},"body":"Hello gitters\n\nSteps to reproduce:\n\n$ git commit --allow-empty -m ‘test’\n$ git revert HEAD\n\nThe latter fails silently, leaving HEAD pointing at the commit created by the first command.\n\nA subsequent `git commit --allow-empty` has the revert message as the default commit message when starting the editor.\n\nHope this is the right place for bugs.\n\nAlistair\n"},{"id":"264275","messageId":"xmqqioakb84v.fsf@gitster.dls.corp.google.com","threadId":"39671","inReplyTo":"A18BC2A3-C9A6-4D03-B929-D821E90B812D@othernation.com","subject":"Re: Bug report: `git revert` on empty commit fails silently","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-06-19T05:05:20Z","receivedAt":"2015-06-19T05:05:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alistair Lynn <alistair@othernation.com> writes:\n\n> $ git commit --allow-empty -m ‘test’\n> $ git revert HEAD\n>\n> The latter fails silently, leaving HEAD pointing at the commit created\n> by the first command.\n\nI do not necessarily think it is a bug to ignore reverting a no-op.\n\"revert a no-op\" should probably fail by default, and the command\nshould require --force or --allow-empty.\n\nBut I agree that silently ignoring is not good.  It should warn the\nuser, saying that reverting no-op is nonsense, when refusing the\nrequest.\n\n> A subsequent `git commit --allow-empty` has the revert message as the\n> default commit message when starting the editor.\n\nAnd leaving a populated MERGE_MSG file to be picked up by the next\ncommit, which is an unrelated operation, is clearly wrong, I would\nthink.  If we deem the \"revert a no-op\" as a nonsense and ignore it,\nwe should ignore it completely and should not leave MERGE_MSG.\n\nBut leaving MERGE_MSG is internally consistent, I think.  When\n\"revert\" stops due to conflicts and returns the control to the user,\nit would explain the situation to the user loudly, and then after\nuser helps Git by resolving the conflict, the user uses \"commit\",\nand the message is picked up from MERGE_MSG.  I'd view what you saw\nvery similar to that situation.  Instead of seeing a conflict (with\nwhich the command cannot automatically continue), the command saw a\n\"no-op\" (which it is dubious that the user really meant to revert).\nAsking the user to help and then allowing the user to signal that\ns/he is now done with \"git commit\" is the right way to continue,\nand for that to work seamlessly, the message has to be in MERGE_MSG.\n\nSo perhaps the only buggy part of this whole experience is that the\ncommand \"silently\" failed, instead of explaining the situation\n(i.e. \"No changes to revert\"); in case the user still does want to\ncommit the revert of no-op by \"commit --allow-empty\", it did the\nright thing by leaving the message in MERGE_MSG to be picked up\nlater.\n\nI dunno.\n\n> Hope this is the right place for bugs.\n\nYes, this is the right place for bugs.\n\nThanks.\n"}]}