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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 28, 2015, 20:42 UTC
Message-ID: <xmqq612ucm3p.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20150928203449.29024.qmail@ns.horizon.com>

"George Spelvin" <linux@horizon.com> writes:

Show 20 quoted lines

> I was applying an old forgotten stash to see if there were any edits in
> it I wanted to preserve, and my old changes to one file made no sense
> any more.  I wanted to drop then all and keep the version in HEAD.
>
> I'd been using git reset <path> after resolving conflicts, to leave
> the changes in the same un-staged state they were before the stash,
> so I tried using "git reset --hard crypto/842.c" to throw away
> my local changes.
>
> And I got
> fatal: Cannot do hard reset with paths.
>
> So I did "git reset <path>" followed by "git checkout <path>", which
> achieved what I wanted.
>
> But what I don't understand is why git reset couldn't do it for me in one
> step.
>
> 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).