"George Spelvin" <li...@horizon.com> 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). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
