Re: bad git pull

From: Junio C Hamano <junkio@cox.net>
Date: Dec 17, 2005, 01:49 UTC
Message-ID: <7vy82kbiho.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0512161701400.3698@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 5 quoted lines

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