{"thread":{"id":"32304","subject":"exit code from git reset","startedAt":"2012-12-09T22:23:41Z","lastAt":"2012-12-09T23:12:29Z","messageCount":3,"participants":["Martin von Zweigbergk","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"204633","messageId":"CANiSa6i0LXE18Pyb5norRTm7PM+TMo3JvxDjoS5JOWt_qjHLHw@mail.gmail.com","threadId":"32304","inReplyTo":null,"subject":"exit code from git reset","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@gmail.com","sentAt":"2012-12-09T22:23:41Z","receivedAt":"2012-12-09T22:23:41Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"Hi,\n\n\"git reset\" currently returns 0 (if successful) while \"git reset\n$pathspec\" returns 0 iff the index matches HEAD after resetting (on\nall paths, not just those matching $pathspec). The exit code doesn't\nseem to be documented. Is there a reason they should behave\ndifferently? If not, what would be the better behavior? I don't see\nwhen the \"git reset $pathspec\" behavior\" would be useful and it seems\nsafer for any existing scripts out there not to change the status code\nfor \"git reset\" (w/o paths). Scripts that run \"git reset $pathspec\"\nprobably already know to ignore (or use?) the exit code. Also, having\nany non-zero exit code signal failure might actually be useful.\n\nChanging \"git reset $pathspec\" to return 0 on success, regardless of\ndiff between HEAD and index, breaks 10 test cases (in\nt2013-checkout-submodule.sh and t7102-reset.sh). These seem to do\n\"test_must_fail git reset $pathspec\", but I have not been able to find\nany motivation for expecting the failure.\n\nIt seems like this behavior has been there at least since the tests\nwere added in 359048d (Add tests for documented features of \"git\nreset\"., 2007-09-11), just before reset became built-in.\n\nWould a patch to change the exit code from \"git reset $pathspec\" be appreciated?\n\nMartin\n"},{"id":"204635","messageId":"7vzk1mddzo.fsf@alter.siamese.dyndns.org","threadId":"32304","inReplyTo":"CANiSa6i0LXE18Pyb5norRTm7PM+TMo3JvxDjoS5JOWt_qjHLHw@mail.gmail.com","subject":"Re: exit code from git reset","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-09T23:04:11Z","receivedAt":"2012-12-09T23:04:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin von Zweigbergk <martinvonz@gmail.com> writes:\n\n> \"git reset\" currently returns 0 (if successful) while \"git reset\n> $pathspec\" returns 0 iff the index matches HEAD after resetting (on\n> all paths, not just those matching $pathspec).\n\nSo in short, you observed that either of them reports with its exit\ncode if the resulting index (not just any subpart, but always the\nentire thing) matches the HEAD, e.g. \"do we have change that will be\nlisted on 'will be committed' section in git status output?\"\n\nSounds like one sane and consistent semantics to me.  I am not\nsaying that there cannot be other behaviours that are internally\nconsistent (e.g. the error code could have matched the number of\npaths that are different between the index and the HED, or the error\ncode could have been zero for successful reset, non-zero for some\nfailure), but I am saying that the current behaviour gives _one_\nsane and consistent meanings regardless of how you ran the command.\n\n> The exit code doesn't seem to be documented.\n\nPlease make it so.\n\n> Changing \"git reset $pathspec\" to return 0 on success, regardless of\n> diff between HEAD and index, breaks 10 test cases (in\n> t2013-checkout-submodule.sh and t7102-reset.sh). These seem to do\n> \"test_must_fail git reset $pathspec\", but I have not been able to find\n> any motivation for expecting the failure.\n\nSee above.\n"},{"id":"204636","messageId":"CANiSa6gPGGDWxpWGsjX0dgBA_SB7-gRKPb5o7EfK0h+DOZauYw@mail.gmail.com","threadId":"32304","inReplyTo":"7vzk1mddzo.fsf@alter.siamese.dyndns.org","subject":"Re: exit code from git reset","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@gmail.com","sentAt":"2012-12-09T23:12:29Z","receivedAt":"2012-12-09T23:12:29Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Sun, Dec 9, 2012 at 3:04 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Martin von Zweigbergk <martinvonz@gmail.com> writes:\n>\n>> \"git reset\" currently returns 0 (if successful) while \"git reset\n>> $pathspec\" returns 0 iff the index matches HEAD after resetting (on\n>> all paths, not just those matching $pathspec).\n>\n> So in short, you observed that either of them reports with its exit\n> code if the resulting index (not just any subpart, but always the\n> entire thing) matches the HEAD, e.g. \"do we have change that will be\n> listed on 'will be committed' section in git status output?\"\n>\n> Sounds like one sane and consistent semantics to me.\n\nHeh, true, the behavior according to my description does make sense,\nit's just that my description was wrong; sorry :-(.\n\nWhat \"git reset $pathspec\" returns is not \"whether HEAD differs from\nindex\" (as I wrote), but \"whether worktree differs from index\". So\n\"git reset\" and \"git reset .\" will return different exit codes if\nthere are changes in the worktree as compared to HEAD before the\ninvocation. I hope that's clearer.\n"}]}