Re: Reset by checkout?

From: Kevin Bracey <kevin@bracey.fi>
Date: Jun 9, 2014, 20:12 UTC
Message-ID: <5396152F.4020704@bracey.fi>
In-Reply-To: <241E3E5EB7AE44E6821EA5DFAA24C28F@PhilipOakley>

On 07/06/2014 17:52, Philip Oakley wrote:

Show 9 quoted lines

>
>
> 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