From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: Disabling credential helper?
Date: Tue, 2 Dec 2014 20:21:48 -0500 [thread overview]
Message-ID: <20141203012148.GB29427@peff.net> (raw)
In-Reply-To: <20141203005953.GB6527@google.com>
On Tue, Dec 02, 2014 at 04:59:53PM -0800, Jonathan Nieder wrote:
> brian m. carlson wrote:
>
> > We've used GIT_ASKPASS=/bin/echo, which seems to solve the problem,
> > although it's ugly and I'm concerned it might break in the future. Is
> > there a better way to do this?
>
> That's a good question. Before falling back to the askpass based
> prompt, Git tries each credential helper matching the URL in turn, and
> there doesn't seem to be an option to override that behavior and disable
> credential helpers.
I think this has nothing at all to do with credential helpers. Git tries
the helpers, of which there are none, and falls back to askpass and
prompting on the terminal. There is no way to design a helper to say "I
tried and failed; do not bother prompting on the terminal". Git only
sees that no helper provided an answer and uses its internal methods.
I did at one point consider making the terminal prompt a credential
helper (since it is, after all, no different from git's perspective;
it's just a mechanism for "somehow" coming up with a username/password
pair). But people generally thought that was unnecessarily complicated
(and it certainly is for the common cases).
> As long as you have no credential helpers configured, your GIT_ASKPASS
> based approach should work fine.
Yeah, it's fine (as is GIT_ASKPASS=true). You could also provide a
credential helper that gives you an empty username and password. But in
both cases, I think that git will then feed the empty password to the
server again, resulting in an extra useless round-trip. You probably
instead want to say "stop now, git, there is nothing else to be done".
We could teach the credential-helper code to do that (e.g., a helper
returns "stop=true" and we respect that). But I think you can do it
reasonably well today by making the input process fail. Sadly setting
GIT_ASKPASS to "false" just makes git complain and then try harder[1].
But you can dissociate git from the terminal, like:
$ setsid -w git ls-remote https://github.com/private/repo
fatal: could not read Username for 'https://github.com': No such device or address
That might have other fallouts if you use process groups for anything. I
have no problem with either an option to disable the terminal prompting,
or teaching the credential-helper interface to allow helpers to stop
lookup, either of which would be cleaner.
-Peff
[1] Courtesy of 84d7273 (prompt: fall back to terminal if askpass fails,
2012-02-03).
next prev parent reply other threads:[~2014-12-03 1:21 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-03 0:03 Disabling credential helper? brian m. carlson
2014-12-03 0:59 ` Jonathan Nieder
2014-12-03 1:21 ` Jeff King [this message]
2014-12-03 1:29 ` Jonathan Nieder
2014-12-03 1:36 ` Jeff King
2014-12-04 1:33 ` Jeff King
2014-12-04 6:07 ` Junio C Hamano
2014-12-03 17:14 ` Junio C Hamano
2014-12-04 0:42 ` brian m. carlson
2014-12-04 3:42 ` [PATCH 0/2] disabling terminal prompts Jeff King
2014-12-04 3:46 ` [PATCH 1/2] credential: let helpers tell us to quit Jeff King
2014-12-04 3:52 ` [PATCH 2/2] prompt: respect GIT_TERMINAL_PROMPT to disable terminal prompts Jeff King
2014-12-04 18:24 ` Junio C Hamano
2014-12-04 21:01 ` Jeff King
2014-12-04 21:33 ` Junio C Hamano
2014-12-05 9:10 ` Jeff King
2014-12-05 17:37 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141203012148.GB29427@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.