Re: Why not git reset --hard <path>?

From: Philip Oakley <philipoakley@iee.org>
Date: Sep 29, 2015, 19:40 UTC
Message-ID: <600ECF9ED63D4A3BAC16F3E29DB656D4@PhilipOakley>
In-Reply-To: <CA+P7+xoTHFL_KU+qBz1KwytxqNTxf1JkjXK7_Ej79uLLnCWD8g@mail.gmail.com>

From: "Jacob Keller" <jacob.keller@gmail.com>

Show 22 quoted lines

> On Mon, Sep 28, 2015 at 1:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> "George Spelvin" <linux@horizon.com> writes:
>>> I understand that "git reset --soft" makes no sense with a path, but
>>> why not --hard?
>>
>> I do not think there is anything fundamentally wrong for wishing for
>> "reset --hard <pathspec>".  It probably is just that nobody needed
>> it, because "git checkout HEAD <pathspec>" is a 99% acceptable
>> substitute for it (the only case where it makes a difference is when
>> you added a path to the index that did not exist in HEAD).
>>
>
> Personally, I would like to see this simply given the number of times
> that I use git reset --hard <path> and then realize I should have used
> git checkout instead. I conceptually think reset --hard should do
> that, and that checkout is really not meant to do that as a concept.
>
> I may have some time to try and give this a look in the next few days...
>
> Regards,
> Jake
> --

I also recently had this problem of expecting to be able to use something like `git reset --hard -- <path>` to clear up some crud and having to cast around for the right approach.

Would it at least be worth flagging up the alternate ` git checkout -- path` a little better within the 'get reset' man pages? At the moment its hidden at the end of the git reset [-q] [<tree-ish>] [--] <paths>… section, so is easily missed.

(i.e. should I flesh out a patch, or would the nuances bury it...?)

Philip