Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> Unfortunately, it can't, because the ref doesn't exist:
>>
>>   $ git ls-remote git://github.com/passcod/UPPERCASE-NPM.git
>>   efc7dbfd6ca155d5d19ce67eb98603896062f35a	refs/heads/MASTER
>>   e60ea8e6ec45ec45ff44ac8939cb4105b16477da	refs/pull/1/head
>>   f35a73dcb151d336dc3d30c9a2c7423ecdb7bd1c	refs/pull/2/head
>>   0d9b3a1268ff39350e04a7183af0add912b686e6	refs/tags/V1.0.0
>>   efc7dbfd6ca155d5d19ce67eb98603896062f35a	refs/tags/V1.0.1
>>
>> There is no HEAD line at all, so we have no information about it on the
>> client side.  Likewise, if you run with GIT_TRACE_PACKET=1, you'll see
>> that the capabilities line does not include a symref marker either.
>>
>> So if we wanted to improve this, I think the first step would be for the
>> server to start sending symref lines for HEAD, even when it does not
>> resolve to anything.
>
> Yup, noticed the same and I agree with your conclusion.

We probably should make head_ref_namespaced() to take the
resolve_flags that is passed down thru refs_read_ref_full() down to
refs_resolve_ref_unsafe().  For the purpose of the first call to it
in upload-pack.c to call back find_symref(), we do not need and want
to say RESOLVE_REF_READING (which requires a symref to be pointing
at an existing ref).  I suspect all the other calls (there are 2
other in unload-pack.c and yet another in http-backend.c) to the
function should keep passing RESOLVE_REF_READING, as they do want to
omit a symbolic ref that points at an unborn branch.