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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"George Spelvin" <linux@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]