On Jul 14, 2013, at 21:13, Junio C Hamano wrote:
Mark Lodato <loda...@gmail.com> writes:

On Fri, Jul 12, 2013 at 3:52 PM, Junio C Hamano <gits...@pobox.com> wrote:

Jonathan Nieder <jrnie...@gmail.com> writes:

FWIW the GIT_SSL_CERT_PASSWORD_PROTECTED envvar has a similar "can
only enable" behavior, but since it's documented, that's not as big
of a problem.  Do you remember why it was written that way?

Not me ;-).

Because that's how GIT_NO_VERIFY, GIT_CURL_FTP_NO_EPSV, and


GIT_CURL_VERBOSE (and perhaps others) work.  That said, I agree that
parsing the variable's value as a boolean would make much more sense.
Perhaps this is how all of those variables should work?

I think you are probably right.

That works fine for GIT_SSL_CERT_PASSWORD_PROTECTED and GIT_CURL_VERBOSE, but it's a little bit awkward for GIT_SSL_NO_VERIFY and GIT_CURL_FTP_NO_EPSV since they have "_NO_" in their names.

If the user wants to override a "http.sslVerify=false" then "GIT_SSL_NO_VERIFY=false" is needed rather than "GIT_SSL_VERIFY=true".

We could:

1) Introduce GIT_SSL_VERIFY and GIT_CURL_FTP_EPSV and say if they are set the "_NO_" version is ignored.

2) Go ahead with "GIT_SSL_NO_VERIFY=false" to force http.sslVerify back to true (and similarly for EPSV).

3) Just leave GIT_SSL_NO_VERIFY and GIT_CURL_FTP_NO_EPSV alone.

4) Do something else, ideas?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to