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

[Jeff King <peff@peff.net>]

On Thu, Feb 04, 2021 at 08:58:31PM -0800, Jonathan Tan wrote:

> diff --git a/Documentation/config/lsrefs.txt b/Documentation/config/lsrefs.txt
> new file mode 100644
> index 0000000000..e003856c08
> --- /dev/null
> +++ b/Documentation/config/lsrefs.txt
> @@ -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 automatically (for example), since the administrator could
> +	configure "allow", then after a delay, configure "advertise".

Minor nit, but did you mean "updated atomically" in the second-to-last
line?

> diff --git a/Documentation/technical/protocol-v2.txt b/Documentation/technical/protocol-v2.txt
> index 85daeb5d9e..f772d90eaf 100644
> --- a/Documentation/technical/protocol-v2.txt
> +++ b/Documentation/technical/protocol-v2.txt
> @@ -192,11 +192,20 @@ 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 will send information about HEAD even if it is a symref
> +	pointing to an unborn branch in the form "unborn HEAD
> +	symref-target:<target>".

I saw there was some discussion back-and-forth on the wording here.
Reading this, I'm left with the impression that an implementation would
be wrong (i.e., violating the protocol) to send a non-HEAD symref with
the unborn value.

I'd have thought we would describe the protocol in the most liberal
fashion, so that clients would be made ready to handle any future
improvements on the server side.

That kind of sounds like the opposite of what Junio said in [1]. And I'm
not sure it's worth re-opening if it's going to derail or delay this
otherwise useful feature. So I offer it as my 2 cents, but not a real
objection to moving forward.

[1] https://lore.kernel.org/git/xmqq1rdyf71k.fsf@gitster.c.googlers.com/

> diff --git a/ls-refs.c b/ls-refs.c
> index a1e0b473e4..e08fd43e7a 100644
> --- a/ls-refs.c
> +++ b/ls-refs.c
> @@ -7,6 +7,39 @@
>  #include "pkt-line.h"
>  #include "config.h"
>  
> +static int config_read;
> +static int advertise_unborn;
> +static int allow_unborn;

OK, we're back to the three-way config. I'm happy with it, as the
default is now "advertise+accept". :)

> +static void ensure_config_read(void)
> +{
> +	char *str = NULL;
> +
> +	if (config_read)
> +		return;
> +
> +	if (repo_config_get_string(the_repository, "lsrefs.unborn", &str)) {

This function leaks "str". I think you can use repo_config_get_string_tmp()
to avoid the allocation entirely.

(I think the initialization to NULL is also unnecessary, but I don't
mind it).

The rest of the patch looks good to me.

-Peff