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

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

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