Subject: Re: [PATCH] receive-pack: crash when checking with non-exist HEAD

From: Junio C Hamano <[email-masked]>
Date: Thu, 23 Jul 2015 10:49:39 -0700

Jeff King <[email-masked]> writes:

> On Wed, Jul 22, 2015 at 01:30:00PM -0700, Junio C Hamano wrote:
>
>> For example, in order to "git commit" from such a state to create
>> the root commit on that branch, existing unrelated branches whose
>> names collide with the branch must be removed, which would mean one
>> of two things, either (1) you end up losing many unrelated work, or
>> (2) the command refuses to work, not letting you to record the
>> commit.  Neither is satisfactory, but we seem to choose (2), which
>> is at least the safer of the two:
>> 
>>     $ git checkout master
>>     $ git checkout --orphan master/1
>>     $ git commit -m foo
>>     fatal: cannot lock ref 'HEAD': 'refs/heads/master' exists;
>>     cannot create 'refs/heads/master/1'
>
> Yeah, that seems sensible. I think the "way out" for the user here would
> presumably be:
>
>   git symbolic-ref HEAD refs/heads/something-else
>
> though of course they could also rename the other ref.

I would have expected you to say

    git checkout --orphan something-else

which should work and would be more intuitive ;-)

> Right. You'd have to teach the is_refname_available() check to always
> check what HEAD points to, and consider it as "taken", even if the ref
> itself doesn't exist. But what about other symbolic refs? The
> "refs/remotes/origin/HEAD" symref may point to
> "refs/remotes/origin/master" even though "refs/remotes/origin/master/1"
> exists. I doubt that will cause real problems in practice, but it points
> out that special cases like "the value of HEAD is magic and reserved"
> will later end up being insufficient as the code is extended.

Yes, we do not have a handy cache of all symrefs, and it is dubious
if this issue is grave enough to warrant adding one.

> I think I'd be willing to simply punt on the whole thing as being too
> rare to come up in practice.

I tend to agree.