Junio C Hamano <gitster@xxxxxxxxx> writes:
> 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.
