Browse Source
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"). To solve this, the remote needs to communicate the target of the HEAD symref, even if it is unborn, and "git clone" needs to use this information. 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" (by default, this is advertised, but server administrators may turn this off through 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. This change is only for protocol v2. A similar change for protocol v0 would require independent protocol design (there being no analogous position to signal support for "unborn") and client-side plumbing of the data required, so the scope of this patch set is limited to protocol v2. The client side will be updated to use this in a subsequent commit. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>maint
Jonathan Tan
4 years ago
committed by
Junio C Hamano
7 changed files with 95 additions and 6 deletions
@ -0,0 +1,9 @@
@@ -0,0 +1,9 @@
|
||||
lsrefs.unborn:: |
||||
May be "advertise" (the default), "allow", or "ignore". If "advertise", |
||||
the server will respond to the client sending "unborn" (as described in |
||||
protocol-v2.txt) and will advertise support for this feature during the |
||||
protocol v2 capability advertisement. "allow" is the same as |
||||
"advertise" except that the server will not advertise support for this |
||||
feature; this is useful for load-balanced servers that cannot be |
||||
updated atomically (for example), since the administrator could |
||||
configure "allow", then after a delay, configure "advertise". |
Loading…
Reference in new issue