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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html