On Fri, Dec 11, 2020 at 01:05:08PM -0800, Jonathan Tan wrote: > 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. -Peff
