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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 2, 2008, 22:17 UTC
Message-ID: <7vabch22ou.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20081030170329.GK24098@artemis.corp>

Pierre Habouzit <madcoder@debian.org> writes:

Show 7 quoted lines

> 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.