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

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

On Tue, Dec 6, 2011 at 2:34 AM, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>> Think about why you need to use git-reset.  Why do new users need to
>> use git-reset?  What is it they are after?
>
> Ok, so let's forget about git reset and let's focus on the features
> instead. If I got it right you suggested the features that people
> wants most often are uncommit, unadd/undelete and undo. Here's a new
> proposal (based on your input):

I flagged this for followup in my MUA, but I failed to follow-up after
the holidays. I apologize for that, and I really regret it because I
liked where this was going.  I only remembered it today when it came
up again in another thread.

> uncommit: git jump <commit> (currently "git reset --soft <commit>")
> unadd/undelete: git unstage file (currently "git reset --mixed file"
> (with "git checkout file" for deleted files)
> undo: git checkout --force --clean <commit> (currently "git reset
> --hard <commit> && git clean -fd")
>
> So, let's try out some scenarios:
>
> 1) Newbie user clones/pulls a repository from somewhere. He hacks
> around and then things go bad, and he decides to scratch away
> everything he did to make sure things are like they're supposed to be.
> He'd then type "git checkout --force --clean master". If he didn't
> introduce new files, he would simply type "git checkout --force
> master"

I like this just fine.  I think we can explicitly say that HEAD is the
implied default refspec, yes?  "git checkout --force --clean"

> 2) Newbie adds some file to the index, then realise he added one too
> many. He wants to remove it from being added. He'd then type "git
> unstage file".

I'm afraid of the word "stage" because of previous discussions about
its i18n abilities.  How about "unadd" and "unrm"?  Or maybe "git undo
add", "git undo rm" and "git undo commit".

The fact that "git undo rm $FILE" works the same as "git checkout HEAD
-- $FILE" and does not truly "undo" the delete operation may make this
a non-starter.  And I admit I have other qualms about using "undo"
even though I keep on introducing it into the discussion.  For
example, this hypothetical sequence will do what I expect when I read
it:

   cp bar foo
   git add foo
   echo "more info" >> foo
   git add foo
   git unstage foo   # now index:foo == HEAD:foo

But if I use "git undo add", it will not

   cp bar foo
   git add foo
   echo "more info" >> foo
   git add foo
   git undo add foo   # index:foo == HEAD:foo, not index:foo == bar

Dang.

Well, I personally am ok with 'unstage' but I expect others will not be.

> 3) Average user creates a commit and suddenly realise he actually
> wanted to split that commit in two (he cannot use --amend, and he's
> not a rebase -i guru yet). Or he did a "temp" commit because he don't
> know about "git stash" yet and wants to discard it. He wants to simply
> go back to the previous state while keeping his changes in the index
> and the worktree. He'd then type "git jump HEAD^1".

I fear the HEAD^1 concept is too much for the newbie.  What about "git
uncommit [$REF]" instead?  It would work like "git reset --soft
$REF^", I think, but maybe it should fail if $REF has multiple
parents.

If the user really wants to uncommit a merge commit, she may need to
use "git unmerge".

Phil