Re: [PATCH] config: option transfer.ipversion to set transport protocol version for network fetches
- From
Alex Riesen <alexander.riesen@cetitec.com>
- Date
- Sep 17, 2020, 14:02 UTC
- Message-ID
- <20200917140254.GA28281@pflmari>
- In-Reply-To
- <xmqqk0wtv204.fsf@gitster.c.googlers.com>
Junio C Hamano, Wed, Sep 16, 2020 23:35:23 +0200:
Show 21 quoted lines
> Junio C Hamano <gitster@pobox.com> writes: > > 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.
If the configuration variable is allowed to be set to that "lack of preference" value, we kind of have a command line option for it:
git -c transfer.protocolFamily=any fetch ...