Martin von Zweigbergk <martinv...@gmail.com> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html