Martin von Zweigbergk <martinvonz@xxxxxxxxx> writes: > "git reset" currently returns 0 (if successful) while "git reset > $pathspec" returns 0 iff the index matches HEAD after resetting (on > all paths, not just those matching $pathspec). So in short, you observed that either of them reports with its exit code if the resulting index (not just any subpart, but always the entire thing) matches the HEAD, e.g. "do we have change that will be listed on 'will be committed' section in git status output?" Sounds like one sane and consistent semantics to me. I am not saying that there cannot be other behaviours that are internally consistent (e.g. the error code could have matched the number of paths that are different between the index and the HED, or the error code could have been zero for successful reset, non-zero for some failure), but I am saying that the current behaviour gives _one_ sane and consistent meanings regardless of how you ran the command. > The exit code doesn't seem to be documented. Please make it so. > Changing "git reset $pathspec" to return 0 on success, regardless of > diff between HEAD and index, breaks 10 test cases (in > t2013-checkout-submodule.sh and t7102-reset.sh). These seem to do > "test_must_fail git reset $pathspec", but I have not been able to find > any motivation for expecting the failure. See above. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html