Jacob Keller <jacob.kel...@gmail.com> writes:
> 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 agree with you if we limit the scope to "reset --hard" that does
not mention any commit on the command line (or says "HEAD").
However, for things like:
$ git reset --hard HEAD^ Makefile
$ git reset --hard HEAD@{4.hours.ago} Makefile
I do not think "reset --hard" is a good match. Conceptually, you
are grabbing what was stored in a given commit and checking that out
to your current workspace (that is, the index and the working tree).
All modes of "git reset" are primarily about updating where in the
history DAG your HEAD points at, and then adjusting your current
workspace to that update, taking into account the reason why you are
repointing your HEAD in the history DAG (e.g. when doing --hard
reset, you want the workspace to match what the commit your HEAD now
points at; when doing --soft reset, you don't want any changes
done).
It is only when you use "git reset" to update your HEAD to point at
the exact same commit when interaction with <pathspec> could make
sense, but conceptually the use case is covered better by
"checkout", which does _not_ futz with the history at all. The
command is primarily about preparing your workspace (that is, the
index and the working tree) toward the work you do to prepare for
the next commit you are going to make. Either you check out a
branch so that your next commit goes to that branch (and you take
your local changes with you when you do so), or you grab contents
from other existing commits to prepare for your work.
So while I am OK with loosening "reset --hard" with <pathspec> if
the command weren't given any commit from the command line, I doubt
that would be a real improvement.
I suspect it may even hurt the users by placing them in a wrong
mental model (i.e. I doubt you would wish "reset --hard <path>" to
work if your starting point were "reset is primarily about moving in
the history DAG and adjust the workspace accordingly").
--
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
