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

From: Jeff King <peff@peff.net>
Date: Mar 2, 2011, 21:27 UTC
Message-ID: <20110302212724.GE20400@sigill.intra.peff.net>
In-Reply-To: <7vlj0yff6m.fsf@alter.siamese.dyndns.org>

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

Show 20 quoted lines

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