Re: [PATCH] builtin-reset.c: Extend hard reset error message when using paths.
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 13, 2009, 19:51 UTC
- Message-ID
- <7vr5zwe3ie.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <1239646444-11653-1-git-send-email-tim@retout.co.uk>
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.
Show 22 quoted lines
> 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