Re: Reset by checkout?

[Kevin Bracey <kevin@bracey.fi>]

On 07/06/2014 17:52, Philip Oakley wrote:
>
>
> Just to say there has been a similar confusion about 'git reset' 
> reported on the Git Users group for the case of reset with added 
> (staged), but uncommitted changes being wiped out, which simlarly 
> reports on the difficulty of explaining some of the conditions 
> especially when some are wrong ;-)
>
> https://groups.google.com/forum/#!topic/git-users/27_FxIV_100

I'm coming around to the view that "git reset <mode>" should be (almost) 
demoted to plumbing, leaving only the "reset <file>" that reverses "add 
<file>" as everyday Porcelain.

I think "reset --keep" and "--merge" were a step in the wrong direction, 
at least for the Porcelain - trying to make reset <mode> "more useful", 
rather than less necessary. Normal users shouldn't be needing to touch 
these hard-to-explain-and-slightly-dangerous commands.

The addition of "--abort" to merge and other commands was much more 
solid. They helped a lot, and I think we should follow that model by 
adding "--undo" to various commands. That would mop up all the common 
"reset"s, in conjunction with Atsushi's proposed "checkout -u" 
alternative to -B, which I quite like.

Main few:

commit --undo = reset --soft HEAD^
merge --undo  = reset --keep HEAD^
rebase --undo = reset --keep ORIG_HEAD   [bug report: rebase -p doesn't 
set ORIG_HEAD reliably]
pull --undo = merge/rebase --undo depending on rebase settings [could we 
go nuts and undo the fetch too?]

Bonus:

commit --amend --undo: reset --soft HEAD@{1}

The undos can also have a bit of extra veneer that checks the log/reflog 
for whether it matches the proposed undo, and also checks the upstream 
to see if the thing being undone is already public.

Given those, I honestly don't think I'd ever need to explain git reset 
<mode> to anyone again. Which would be nice...

(Note I propose no "--mixed" equivalent for the commit undos, but it's 
easy enough to follow the "commit --undo" with a normal "git reset". I'd 
rather re-document the normal git reset under "commit --undo" than add 
and document yet another option).

Kevin