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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 2, 2011, 02:07 UTC
Message-ID: <7vlj0yff6m.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110301205424.GA18793@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 14 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.

Perhaps that needs to be changed to have the same safety? IOW, regardless of your "checkout" destination, whenever you leave a detached commit that would become unreachable, we should warn the same way?

I suspect I would loath it as being too loud; I dunno...