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

From: Jacob Keller <jacob.keller@gmail.com>
Date: Sep 29, 2015, 07:06 UTC
Message-ID: <CA+P7+xrzmDHyseGaJFkyUGUi=Uep0LLhPdZDeo3NeBBmXJTZWw@mail.gmail.com>
In-Reply-To: <xmqqvbaub5s4.fsf@gitster.mtv.corp.google.com>

On Mon, Sep 28, 2015 at 2:19 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

> I agree with you if we limit the scope to "reset --hard" that does
> not mention any commit on the command line (or says "HEAD").
>
> However, for things like:
>
>     $ git reset --hard HEAD^ Makefile
>     $ git reset --hard HEAD@{4.hours.ago} Makefile
>
> I do not think "reset --hard" is a good match.  Conceptually, you
> are grabbing what was stored in a given commit and checking that out
> to your current workspace (that is, the index and the working tree).
>

Agreed. I just get used to thinking about using it against HEAD. it's just weird to me that something which sometimes switches branches is also the thing to grab a version of a file.

reset hard really would be weird in this case, because you really don't know if the user meant "rewind the history, but keep everything *except* that listed file..

That makes sense now that I think about it. Thanks.

Regards, Jake