Re: bad git pull

Linus Torvalds <torvalds@osdl.org> writes:

I agree to this in principle, but I am afraid "git undo" is too generic and fuzzy a term. Things you might possibly want to undo depends on what you did last [*1*]. In most undoable cases, "reset --hard" is almost right but most likely would result in information loss.

If we want to really newbie-proof the "undo" command, I think the hard ones are not the ones that can be approximated with reset ORIG_HEAD, but other "No way to undo" ones and "Nothing to undo" ones.

Earlier on the list I gave an overview on merge for an unnamed person with only an e-mail address, and one thing struck me as quite hard to explain was that there are two kinds of "merge failures" --- ones that did not even start the merge and ones that failed in the middle due to conflicts. Somebody totally new to git, after seeing "git pull" to fail in the first kind, would get scared and type "git undo". We could prevent doing damage by making sure we remove ORIG_HEAD in "Nothing to undo" situations, but if we say "Nothing to undo" when the user types "git undo" in such a situation, we will surely hear "what do you mean? the command said failed to pull and I wanted to recover from that!".

It also is not clear if it is wise to clear ORIG_HEAD for "No way to undo" ones. Doing so would rob useful undo information from people who know git and expect "No way to undo" ones do not muck with the existing ORIG_HEAD.

Even for the ones that we would do "reset --hard ORIG_HEAD", many lose information, and "undo" to me implies "undo only what the last command messed up", which is not what actually happens.

The word "reset" does not have that connotation -- it takes you to some defined state, which may be close to what you had before but may not be exactly the same if you had local changes in your tree. HEAD, ORIG_HEAD, and HEAD^ are such defined states you can go, and the user gives where he wants to go explicitly. "undo" does not really say where to go and hides halfway what we do, without doing exactly what the user would expect (and cannot be implemented fully unless we are willing to take a snapshot of working tree, I suspect).

[Appendix]

*1* List of commands that a user might want to undo.

A merge or non-merge commit, cherry-pick, and revert::
	reset --hard HEAD^ ;# this can be helped by leaving ORIG_HEAD
                            # but "--hard" is not quite right;
                            # your working tree could have been
                            # dirty at irrelevant paths

A fetch fast-forwarding non-current branch::
	No way to undo -- we do not keep the old information.

A merge, that was fast-forward::
	reset ORIG_HEAD ;# never "--hard" -- your working tree could
                         # have been dirty and in this case
                         # there is no information loss.

A merge attempt, conflicted::
	reset --hard ORIG_HEAD
                         # again, "--hard" is not quite right --
			 # your working tree could have been
                         # dirty at irrelevant paths.

A merge attempt, did not even start because index or tree was dirty::
	Nothing to undo.

A successful checkout (switch branch)::
	No way to undo -- we do not keep the old information.

git-update-index and git-add::
	No way to really undo -- we do not keep the old
	information.  The closest is "git reset" but it reverts
	more than the last operation.

rebase::
	reset --hard ORIG_HEAD

am/applymbox::
        No way to undo -- we do not keep the old information.
			;# this can be helped by leaving ORIG_HEAD