Re: [PATCH] builtin-reset.c: Extend hard reset error message when using paths.

[Junio C Hamano <gitster@pobox.com>]

Tim Retout <tim@retout.co.uk> 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@retout.co.uk>
> ---
>  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