> > 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. All this sounds good. > > 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. OK - thanks for your comments. I'll send out an updated version soon.
