Re: [Wishlist] could git tell which password it is asking when asking a password.

Rémi Vanicat [off-list ref] writes:

When git is asking for a password (for example for pushing over https)
it call the $GIT_ASKPASS script with only "Password: " as a an argument,
so when one have several remote, it might not know which one is asking
the password. 

On the C side, git_getpass() is the function to touch. It has only three
callers.

In init_curl_http_auth() in http.c, we know "user_name" but we do not give
it as a hint when coming up with a prompt.  A possible update to the
git_getpass() API would be to make the call look like this:

diff --git a/http.c b/http.c
index a1ea3db..ee3e821 100644
--- a/http.c
+++ b/http.c

@@ -214,7 +214,7 @@ static void init_curl_http_auth(CURL *result)
 	if (user_name) {
 		struct strbuf up = STRBUF_INIT;
 		if (!user_pass)
-			user_pass = xstrdup(git_getpass("Password: "));
+			user_pass = git_getpass(_("Password for %s: "), user_name);
 		strbuf_addf(&up, "%s:%s", user_name, user_pass);
 		curl_easy_setopt(result, CURLOPT_USERPWD,
 				 strbuf_detach(&up, NULL));

The points are

 (1) to show identity for which the password is being asked for;
 (2) to give a fresh and stable memory, making it unnecessary to
     xstrdup() while at it.

The same thing for the call in has_cert_password(), which may want to use ssl_cert
as the identifier.

There is an abuse of git_getpass() in http_request() to ask for the
username. It inherits the "noecho"-ness of git_getpass() which gives a
bad user experience. We _may_ want to give another parameter to git_getpass()
to specify if we want noecho.

The other call is from imap-send.c that knows srvc->user and srvc->host
and formulates the prompt including the identity. So an alternative route
may be to keep git_getpass() as-is, and update the init_curl_http_auth()
callsite to include the username (but imap-send assumes that user and host
are relatively short without verifying that assumption, and should not be
used as a model of good existing code).

It would be interesting also to plug some sort of password-safe unto
git, or some "git-agent". 

I am not particularly interested in seeing git specific agent. Something
that can be called as an external process that talks with existing
practices (gpg agent and friends) would be nice.