Re: bad git pull

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

Linus Torvalds <torvalds@osdl.org> writes:

> Or maybe "git commit" should always _write_ ORIG_HEAD with the old head, 
> so that we can always do an "undo" by doing "git reset --hard ORIG_HEAD" 
> regardless of whether the last thing was a "git commit" or a "git pull".
>
> Hmm?

If we define "git undo" as "Revert the tree to the state one
before the last successfull commit/pull", then overwriting
ORIG_HEAD as you say at the commit time and always using "git
reset --hard ORIG_HEAD" would make sense.

I fail to see the merit of "git undo/unpull/unmerge/..."; mostly
because I have never seen BK and do not benefit from the
familiarity factor at all.  To people without BK experience,
having too many synonyms (e.g. "git undo" does something magical
by feeding "git reset --hard" with ORIG_HEAD) might be just more
noise and confusion.  I can see them asking "why are there two
ways to do identical things?".

However, the reason I am maintaining git is not to make it
useful for _me_, but to make it useful for the kernel people, so
if these BK-like synonyms help them, I'm all for it.  If we are
going to do that, somebody needs to describe what should each
command do in each case in detail, because I do not know BK at
all.

You guys were on BK for how many months, and have been on git
for how many months now?  Do BK-familiarity factor matter, and
will it continue to matter for how long?