Re: [PATCH] clone: in protocol v2, use remote's default branch

> > Subject: Re: [PATCH] clone: in protocol v2, use remote's default branch
> > 
> > When cloning an empty repository, a default branch is created. However,
> > it is named after the locally configured init.defaultBranch, not the
> > default branch of the remote repository.
> 
> Your subject line puzzled me at first, because I thought we already did
> that. And indeed we do, but this is about adding the unborn case. I
> think this contributed to Ævar's confusion.
> 
> Maybe:
> 
>   Subject: clone: respect unborn remote HEAD
> 
>   When cloning, we choose the default branch based on the remote HEAD.
>   But if there is no remote HEAD, we'll fall back to using our local
>   init.defaultBranch. Traditionally this hasn't been a big deal, because
>   everybody used "master" as the default. But these days it is likely to
>   cause confusion if the server and client implementations choose
>   different values (e.g., if the remote started with "main", we may
>   choose "master" locally, create commits there, and then the user is
>   surprised when they push to "master" and not "main").
> 
>   To solve this...
> 
> makes the current state more clear, as well as motivating why we care.
> 
> It might also be worth breaking the patch up a bit. E.g., implement the
> capability in upload-pack, then infrastructure for the client to use the
> capability and surface the info to transport callers, and then finally
> surface it to in the program logic of ls-refs, then clone, etc.
> 
> Not strictly necessary, but it make it easier to see what is being
> changed at each step.

> > Currently, symrefs that have unborn targets (such as in this case) are
> > not communicated by the protocol. Teach Git to advertise and support the
> > "unborn" feature in "ls-refs" (guarded by the lsrefs.unborn config).
> > This feature indicates that "ls-refs" supports the "unborn" argument;
> > when it is specified, "ls-refs" will send the HEAD symref with the name
> > of its unborn target.
> 
> It's probably also worth mentioning that v0 won't get any support here,
> and why.