Re: bad git pull

Linus Torvalds [off-list ref] 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?

On Fri, 16 Dec 2005, Junio C Hamano wrote:

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?

I don't think it is a huge deal, I suspect that people who used BK have a 
much easier time with git if only because they already understand the 
whole distributed thing and about commits and merges.

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".

		Linus