Re: bad git pull

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

> That said, I think a lot of newbies might want to have a "git undo", and 
> not because of any BK history. Even if it just ends up being nothing but 
> shorthand for "git reset --hard ORIG_HEAD".

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