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

[Jeff King <peff@peff.net>]

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