Re: [PATCH] Detached HEAD (experimental)

From: Junio C Hamano <junkio@cox.net>
Date: Jan 2, 2007, 22:44 UTC
Message-ID: <7virfprquo.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87ps9xgkjo.wl%cworth@cworth.org>

Carl Worth <cworth@cworth.org> writes:

Show 14 quoted lines

> On Mon, 01 Jan 2007 23:45:08 -0800, Junio C Hamano wrote:
>> This allows "git checkout -d v1.4.3" to detach the HEAD from any
>> branch but point directly at the named commit.
>
> Being able to perform "checkout" with a tag like this, (and no
> specific branch), is something I've been wanting git to acquire for
> some time. So, thanks for coding this up!
>
>> This is still experimental.  While I think it makes sense to
>> allow commits on top of detached HEAD, it is rather dangerous
>> unless you are careful and know what you are doing.
>
> This part I don't understand. I don't see why it's useful to introduce
> new danger to "git checkout"...

I am not saying being risky is useful. That's why I said it is experimental.

We could do two things, and I think disallowing commits is not necessarily a better option of the two. We could allow commits and prevent the user from switching out of the detached HEAD state without an explicit action instead. If we go the first route, you need to also prevent merges into the detached HEAD. If we go the latter I think you only need to add a check in "git-checkout" but there may be other cases. In either way, we need a safety valve, which the experimental code does not have.

And being able to merge into the detached HEAD turns out to be somewhat useful. I checked out the v1.4.4.3 and tried to see if a topic is applicable by merging into that detached HEAD and running testsuite. Of course, without any safety valve, I can easily lose the merge result by switching out of the detached HEAD state (say, "git checkout master"), but on the other hand, creating a new branch at that point with "git checkout -b v1.4.4.3-maint" would let me continue from that point without losing anything.

But this is only "somewhat" -- I do not have strong opinion either way, other than that we need a safety valve (which we agree).

In any case, I did this because I got tired of waiting for it to happen (I thought you wanted to hack on this over the long week^W yearend, so I deliberately stayed away from doing this) and I was bored. This will not be in 'next' in the current shape.

You've thought about the issue long enough to write your commentary and I agree to most of your points (including favoring "no commit allowed in this state" over "allow commits and merges to help advanced usage" for its simplicity), so if you code it up with a clean patch, I would not reject it on the basis of its design.