Re: Proposal: create meaningful aliases for git reset's hard/soft/mixed

From: Phil Hord <phil.hord@gmail.com>
Date: Dec 1, 2011, 21:02 UTC
Message-ID: <CABURp0oAvt4uES1kjqE0OfSiS9DR6Uj+0bf=zgUi5qkw0rqCSQ@mail.gmail.com>
In-Reply-To: <7vlir6brjw.fsf@alter.siamese.dyndns.org>

On Wed, Nov 23, 2011 at 1:51 PM, Junio C Hamano <gitster@pobox.com> wrote:

> "git reset --hard HEAD" is an unambiguously descriptive good name for the
> option. It is a "hard reset" like power cycling a machinery to discard
> anything in progress and get back to a clean slate. I do not see anything
> confusing with this mode nor its name.

As a git expert-user, I agree.

But, honestly, as a git new-user, I had a lot of trouble with this command. It is mysterious and powerful and new users do not understand it. Everyone learns "git reset --hard HEAD" as a single command. Only much later (if ever) do they learn about the other git-reset options. --hard is the only useful option for the new user, so it seems superfluous. HEAD is a foreign concept for the new-user and makes little sense when this command is first memorized. And at the early stages of the git learning curve, that's what it is: memorized. _The spelling is what counts; the meaning is mysterious._ (For all its flaws, though, at least "git reset --hard HEAD" serves to introduce the new-user to the concept of HEAD.)

So, as a git new-user, what I wanted was this:
  git clean-checkout [or "git checkout --clean"]

What I found instead was this:
  git reset --hard HEAD

What does this have to do with "checking out my files from the last commit" or "discarding my local, uncommitted edits"? To the new-user, nothing at all. reset? Meaningless. --hard? Whatever. HEAD? Shrug.

In the end it doesn't even do what I wanted.  What I really wanted was this:
  git reset --hard HEAD && git clean -fd

I think the git-reset modes should be relegated to plumbing. I can see how 'git reset --mixed' is useful for resetting changes out of the index, but reset is so mired in all sorts of extra mumbo-jumbo that this usage becomes a forgotten detail for me. I didn't even learn that usage until later, where it makes loads of sense on its own:

     FTH: This means that git reset <paths> is the opposite of git add <paths>.

That is beautiful, clean and useful.  If that's all it did, it would be perfect.

Problems with git-reset--hard:
 * It has no safety nets (except the reflog, another concept foreign
to new-users)
 * It requires extra switches/arguments to be useful
 * Surprisingly (at first), it can move your branch, but it's not
spelled 'branch' or 'commit' or 'move'

That last one is particularly troubling in light of the description of
'git reset --hard':
     Resets the index and working tree. Any changes to tracked
     files in the working tree since <commit> are discarded.

Maybe we should add "and by the way, your currently checked-out branch is moved to point to <commit>".

</rant>

Phil