On Jul 14, 2013, at 21:13, Junio C Hamano wrote:
Mark Lodato <lodatom@xxxxxxxxx> writes:
On Fri, Jul 12, 2013 at 3:52 PM, Junio C Hamano <gitster@xxxxxxxxx>
wrote:
Jonathan Nieder <jrnieder@xxxxxxxxx> 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
s/GIT_NO_VERIFY/GIT_SSL_NO_VERIFY/, I think.
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?
Comments?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html