Re: Reset by checkout?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]