From: Sam Vilain <sam@vilain.net>
Date: Mon, 03 Nov 2008 06:01:11 GMT
Subject: Re: [PATCH] Documentation: add a planning document for the next CLI revamp
Message-ID: <1225692071.20883.44.camel@maia.lan>
In-Reply-To: <7vabch22ou.fsf@gitster.siamese.dyndns.org>

On Sun, 2008-11-02 at 14:17 -0800, Junio C Hamano wrote:
> 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.

Interesting.

I'm wondering whether the important thing here is not making a new
command, but simply deprecating "revert", and pointing the user to "git
reset" - then making sure that you can do everything revert-like (eg, as
Elijah points out) from that command.

Sam.