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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
