Re: [PATCH] config: option transfer.ipversion to set transport protocol version for network fetches
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 16, 2020, 21:35 UTC
- Message-ID
- <xmqqk0wtv204.fsf@gitster.c.googlers.com>
- In-Reply-To
- <xmqqtuvxwkbz.fsf@gitster.c.googlers.com>
Junio C Hamano <gitster@pobox.com> writes:
Show 27 quoted lines
> Also, we should follow the usual "the last one wins" for a
> configuration variable like this, which is *not* a multi-valued
> variable. So the config parsing would look more like this:
>
> if (!strcmp(k, "transfer.ipversion")) {
> if (!v)
> return config_error_nonbool("transfer.ipversion");
> if (!strcmp(v, "any"))
> family = 0;
> else if (!strcmp(v, "4") || !strcmp(v, "ipv4"))
> family = TRANSPORT_FAMILY_IPV4;
> else if (!strcmp(v, "6") || !strcmp(v, "ipv6"))
> family = TRANSPORT_FAMILY_IPV6;
> else
> return error("transfer.ipversion: unknown value '%s'", v);
> }
>
> Would we regret to choose 'ipversion' as the variable name, by the
> way? On the command line side, --transfer-protocol-family=ipv4
> makes it clear that we leave room to support protocols outside the
> Internet protocol family, and existing --ipv4 is grandfathered in
> by making it a synonym to --transfer-protocol-family=ipv4. Calling
> the variable "transfer.ipversion" and still allowing future protocols
> outside the Internet protocol family is rather awkward.
>
> Calling "transfer.protocolFamily" would not have such a problem,
> though.In case it wasn't clear, I consider the current TRANSPORT_FAMILY_ALL a misnomer. It's not like specifying "all" will make us use both ipv4 and ipv6 at the same time0---it just indicates our lack of preference, i.e. "any transport protocol family would do".
I mention this because this topic starts to expose that 'lack of preference' to the end user; I do not think we want to use "all" as the potential value for the command line option or the configuration variable.
Thanks.