Re: [PATCH v6 1/3] ls-refs: report unborn targets of symrefs

Jonathan Tan [off-list ref] 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.

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?

quoted

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.

Right now, that's true.

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?

I'm not sure what the ideal endgame state is, but I could see how
sending all symlinks would be useful (e.g. if a client wanted to mirror
another repo with more fidelity). Right now I don't plan on adding
support for dangling symrefs other than HEAD, though. Maybe I'll update
it to something like:

  If HEAD is a symref pointing to an unborn branch, the server may send
  it in the form "unborn HEAD symref-target:<target>". In the future,
  this may be extended to other symrefs as well.

I think that there is a discussion point to be decided
(advertise/allow/ignore vs allow/ignore), so I'll wait for that before
sending v7.