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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> writes:

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


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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]