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

From: Junio C Hamano <[email-masked]>
Date: Mon, 28 Sep 2015 13:42:02 -0700

"George Spelvin" <[email-masked]> writes:

> 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).