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

> been trying to keep up...
>
> From: "Jeff King" <peff@peff.net>
>> On Thu, May 25, 2017 at 11:59:24AM -0400, Jeff King wrote:
>>
>>> The just-HEAD case could look like:
>>
>> This patch does work, in the sense that upload-pack advertises the
>> unborn HEAD symref. But the client doesn't actually do anything with it.
>> The capability parsing happens in get_remote_heads(), which passes the
>> data out by adding an annotation to the "struct ref" list. But of course
>> we have no HEAD ref to annotate.
>>
>> So either get_remote_heads() would have to start returning a bogus HEAD
>> ref (with a null sha1, I guess, which all callers would have to
>> recognize). Or clone (and probably "remote set-head -a") would have to
>> start reaching across the transport-module boundary and asking for any
>> symref values for "HEAD". I'm not excited about more special-casing of
>> "HEAD", though. In theory we'd want this for other symrefs in the long
>> run, and it would be nice if clients were ready to handle that (even if
>> the protocol isn't quite there).
>>
>> I dunno. I was thinking there might be a quick tweak, but I'm wondering
>> if this arcane case is worth the restructuring we'd have to do to
>> support it. It only comes up when you've moved the server repo's HEAD to
>> an unborn branch _and_ you have other refs (since otherwise we don't
>> even send capabilities at all!).
>>
>> -Peff
>
> My original comment regarding Felix's report was based on when I was 
> looking at the bundle code's disambiguation of refs which matched HEAD's 
> sha1. Hence I had a mis-remembered impression that the HEAD - symref 
> matching was avaibable.
>
> At that time, Junio had suggested that, at least in the bundle file, the 
> HEAD symref could be advertised immediately after a nul on the ref line.
>
> At least for regular git, the sha1and symref value would included in the 
> read line, and the current string processing [1] would not notice the 
> extra symref data. This extra data could then be read (if present) from 
> the end of the line, and the HEAD symref set.
>
> What I then noticed (but didn't report to the list) was the option of 
> adding that extra info to the PKLINE protocol.
>
> <from my notes>
> In technical\pack-protocol.txt #L136;158-160
> Reference Discovery:
>
> If HEAD is a valid ref, HEAD MUST appear as the first advertised
> ref.  If HEAD is not a valid ref, HEAD MUST NOT appear in the
> advertisement list at all, but other refs may still appear.
> -
>
> So, (for both upload pack, and bundle refs) the place to hide the HEAD is 
> after the later ref that HEAD points to.
> e.g.(updating the example at #L147):
>   00441d3fcd5ced445d1abc402225c0b8a1299641f497 
> refs/heads/integration\0HEAD[LF]
>
> The potential issue is if there is a passed ref that is HEAD, but that 
> HEAD itself isn't passed (especially for bundle)
> <\from my notes>
> --
>
> However given the discussion about an unborn HEAD, the option here would 
> be to also pass the NULL sha for the symref and then add the annotation 
> 'HEAD' after an extra \0, in the same way that an active symref could be 
> annotated with the '\0HEAD'. This would kill two birds with one stone!
>
> These are still protocol changes but should squeeze into the existing 
> processing using the \0 trick.
>
> In the absence of the information, and the multi-use of the warning 
> function, the current message is possible the best we can get.
>
> Philip
>
> [1] the question would be whether other git versions also use the same 
> string processing so could be 'fooled' in the same way? I'd be interested 
> to know if that was a possibility.
>