Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: > When cloning, we choose the default branch based on the remote HEAD. > But if there is no remote HEAD reported (which could happen if the > target of the remote HEAD is unborn), we'll fall back to using our local > init.defaultBranch. Traditionally this hasn't been a big deal, because > most repos 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"). > ... > The client side will be updated to use this in a subsequent commit. Nicely explained. > diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt > index 85daeb5d9e..4707511c10 100644 > --- a/Documentation/technical/protocol-v2.txt > +++ b/Documentation/technical/protocol-v2.txt > @@ -192,11 +192,19 @@ ls-refs takes in the following arguments: > When specified, only references having a prefix matching one of > the provided prefixes are displayed. > > +If the 'unborn' feature is advertised the following argument can be > +included in the client's request. > + > + unborn > + The server may send symrefs pointing to unborn branches in the form > + "unborn <refname> symref-target:<target>". > + I somehow had an impression that this is done only for HEAD and no other symrefs. If this describes the ideal endgame state and the implementation at the moment only covers what is practically the most useful (i.e. HEAD), that is fine. If we do not plan to support symrefs other than HEAD that are dangling, that is fine as well, but then the description needs updating, no?
