[PATCH] git-svn: favor ~/.subversion/ ssl client cert settings

[PATCH] git-svn: favor ~/.subversion/ ssl client cert settings

[Michael Krelin]

---
 git-svn.perl |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/git-svn.perl b/git-svn.perl
index 50128d7..9dfea97 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2925,6 +2925,7 @@ sub new {
 	    SVN::Client::get_ssl_server_trust_file_provider(),
 	    SVN::Client::get_simple_prompt_provider(
 	      \&Git::SVN::Prompt::simple, 2),
+	    SVN::Client::get_ssl_client_cert_file_provider(),
 	    SVN::Client::get_ssl_client_cert_prompt_provider(
 	      \&Git::SVN::Prompt::ssl_client_cert, 2),
 	    SVN::Client::get_ssl_client_cert_pw_prompt_provider(
-- 
1.5.2.2

Re: [PATCH] git-svn: favor ~/.subversion/ ssl client cert settings

[Junio C Hamano]

Sorry, but I am not familiar with SVN API.

In plain English, what does this change mean and what does it
buy us?  An expected answer is something like:

	Without this change, there is no way to authenticate
        with client SSL certificates, as certificates registered
        in ~/.subvsersion are ignored.

BTW, if that is what you meant, it contradicts the word "favor"
in the proposed commit title.  "Favor" would mean "We do support
it already but in lower precedence than something else, which is
inconvenient, so let's move it up so that it is used if found
without bothering other possibilities".  

If that is what you really meant, then the answer would be in
the form of:

	Curently, even when the client wants to use SSL
        certificate to authenticate with the server, X
        authenticator is tried first which causes Y that is
        irritating.  This patch makes the client certificate
        authenticator be tried first.

But if that is what is going on, we need to judge if the
"irritation" factor is universally true, or just affects people
who want to use client SSL cert; if the change makes it more
convenient for client cert people by making it less convenient
for others, the relative merit needs to be debated to justify
the change.

I am guessing that you meant the former (we currently totally
ignore it, and the patch adds the missing support), but what
would I know...

And if that is the case, then I think the word you wanted to use
is not "favor" but "honor".

In any case, the patch needs a handful lines of proposed commit
log message to explain and justify the change, like the above
two examples I showed here.