Re: [PATCH v2 3/3] connect: Add the envvar GIT_SSH_VARIANT and ssh.variant config

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 1, 2017, 16:53 UTC
Message-ID: <xmqqlgtpq2cz.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1702011216130.3469@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 11 quoted lines

> On Fri, 27 Jan 2017, Junio C Hamano wrote:
>
>> IOW, I think it is acceptable to always split GIT_SSH_COMMAND into
>> tokens before we realize that the user used the escape hatch and the
>> splitting was a wasted effort.  This is exactly because this thing
>> is an escape hatch that is expected to be rarely used.  Of course,
>> if the "wasted effort" can be eliminated without sacrificing the
>> simplicity of the code, that is fine as well.
>
> Simplicity is retained. Battle-readiness was sacrificed on the way: the
> new code is not tested well enough, and `next` will not help one bit.

Let me make it clear that there is no burning desire to sacrifice battle-readiness in the above. If we expect that auto-detection would be minority, then it makes sense to get the configured value first and then spend cycles to split and guess only when detection is needed.

In this case, because we expect that auto-detection will be used most of the time, it is good enough to always split first, get the configured value, and spend cycles to guess, or for that matter it is perfectly fine to always split and guess first and then override with the configured value.

If your attempt to optimize for a wrong case ended up causing new unnecessary bugs, don't blame me.