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

[Phil Hord <phil.hord@gmail.com>]

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