Re: [PATCH] Documentation: add a planning document for the next CLI revamp

[Junio C Hamano <gitster@pobox.com>]

Pierre Habouzit <madcoder@debian.org> writes:

> On Thu, Oct 30, 2008 at 05:00:18PM +0000, Nicolas Pitre wrote:
>
>> If you have a file argument, the --hard option is redundant, isn't it?
>> So what about simply "git reset <file>" ?
>
> errrrm, git reset <file> resets the index notion of the file to its status
> in HEAD... which I'm sure is *somehow* useful to "some" people ;P

I'd agree that 'reset' is rather unfortunate.  It very originally was all
about the index (the "mixed" semantics, specifically "git reset" without
any committish nor any pathspec, was the original use case) and nothing
else.  IOW, "I staged a wrong change, let's start over by discarding all
staged changes".  A logical extension to it is "git reset -- pathspec",
IOW, "I know which paths I fubared, please reset only these paths, as
other staged changes are Ok".

So "reset <file>" is very much useful.

Then 'reset' learned to also muck with HEAD, so "reset HEAD^" (still
mixed, without any pathspec) can be used to amend the latest commit but
without losing the state you would eventually want to arrive at.  A
logical extension to this was "git reset --hard HEAD^" to nuking instead
of amending the mistake, and "git reset --soft HEAD^" to save the trouble
of staging the changes when the mistake you are fixing is small compared
to the entire change.

"checkout [$committish] $path" came much later, and the command is all
about index and files, and never about resetting HEAD.  "checkout $path"
does "reset --hard $path" (notice there is no $committish in either one)
would have done, so we stopped enhancing the "reset" command in that
direction.