From: "Jacob Keller" <jacob.kel...@gmail.com>
On Mon, Sep 28, 2015 at 1:42 PM, Junio C Hamano <gits...@pobox.com> wrote:
"George Spelvin" <li...@horizon.com> writes:
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).
Personally, I would like to see this simply given the number of times
that I use git reset --hard <path> and then realize I should have used
git checkout instead. I conceptually think reset --hard should do
that, and that checkout is really not meant to do that as a concept.
I may have some time to try and give this a look in the next few days...
Regards,
Jake
--
I also recently had this problem of expecting to be able to use something
like `git reset --hard -- <path>` to clear up some crud and having to cast
around for the right approach.
Would it at least be worth flagging up the alternate ` git checkout --
path` a little better within the 'get reset' man pages? At the moment its
hidden at the end of the git reset [-q] [<tree-ish>] [--] <paths>… section,
so is easily missed.
(i.e. should I flesh out a patch, or would the nuances bury it...?)
Philip
--
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
