Jeff King <peff@xxxxxxxx> 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.
--
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