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

Jeff King [off-list ref] writes:

On Wed, Jul 22, 2015 at 01:30:00PM -0700, Junio C Hamano wrote:

quoted

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.