Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)

[Jeff King <peff@peff.net>]

On Tue, Mar 01, 2011 at 06:07:29PM -0800, Junio C Hamano wrote:

> > On Mon, Feb 28, 2011 at 08:52:08AM -0800, Junio C Hamano wrote:
> >
> >> I am not convinced that this patch nailed that balance at exactly the
> >> right place, even though I think we are getting closer than before.  In
> >> this sequence:
> >> 
> >>     $ git checkout somewhere^0
> >>     $ git commit
> >>     $ git reset --hard somewhere_else
> >>     $ git commit
> >>     $ git checkout master
> >> ...
> > I really wouldn't expect it to help here. The problem isn't that you're
> > on a detached HEAD. It's that you're using "git reset" at all.
> 
> As you would realize later in your message, the "reset --hard" can instead
> be "checkout v1.7.3".  And the bothersome thing is that there is no safety
> against that.  We don't bother users while they are jumping around on
> detached HEAD, and it is not new; we don't say where the previous detached
> HEAD was.

No, "checkout v1.7.3" should engage the safety valve. And in your patch,
it does. So replacing your reset --hard with checkout _is_ safe. And I
think that behavior is reasonable. Reset's purpose is about shifting
HEAD to drop history, whether you are on a detached HEAD or not. Having
it warn would be annoying and pointless.

Checkout, on the other hand, is about moving your working tree to a
different place in history, and we _should_ warn about dropping history.
So it is really just a matter of educating users to use the appropriate
tool for sight-seeing (and I don't think there is much education to be
done; checkout seems like the obvious choice given it is how you got to
the first commit).

-Peff