Tim Retout <tim@xxxxxxxxxxxx> writes:
> Users who invoke 'git reset --hard <paths>' are probably trying to
> update paths in their working directory. The error message should
> point them in the direction of git-checkout(1).
That is one possibility. Another is:
git reset --hard mester
(and you have ./mester file in the work tree) and in that case the user
definitely didn't want to do any checkout.
I wonder if you can tell these cases apart, and also if this (not just
telling these apart, but what your patch adds) is worth additional
cluttering in the running program. I certainly wouldn't mind addition to
git-reset manual page if new people are often confused between "checking
out paths from the index or from the named commit" and "resetting the HEAD
to a different commit while nuking the index and the work tree state",
though.
> Signed-off-by: Tim Retout <tim@xxxxxxxxxxxx>
> ---
> builtin-reset.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-reset.c b/builtin-reset.c
> index c0cb915..885ca9a 100644
> --- a/builtin-reset.c
> +++ b/builtin-reset.c
> @@ -257,6 +257,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
> if (i < argc) {
> if (reset_type == MIXED)
> warning("--mixed option is deprecated with paths.");
> + else if (reset_type == HARD)
> + die("Cannot do %s reset with paths.\n"
> + "See git-checkout(1) to update paths in the working tree.",
> + reset_type_names[reset_type]);
> else if (reset_type != NONE)
> die("Cannot do %s reset with paths.",
> reset_type_names[reset_type]);
> --
> 1.6.2.2
--
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