When cloning git repositories in automated tools - web front ends, CI systems, sometimes the git clone invocation opens up a prompt asking for the username and password (for example, when cloning a non-existent Github repo or on a new node missing ssh keys).
How do I make git just fail (preferably with a sensible error message and exit code) instead of waiting for the server process to give it a username and password?
In git version 2.3 there's an environment variable GIT_TERMINAL_PROMPT which when set to 0 will disable prompting for credentials.
You can get more info about it in man git (after updating to git version 2.3) or in this blog post on github.
Examples:
git clone https://github.com/some/non-existing-repo will prompt for username & passwordGIT_TERMINAL_PROMPT=0 git clone https://github.com/some/non-existing-repo will fail without prompting for username & passwordThe answers above only worked partly for me when using Git-for-Windows: two different applications there were vying for my attention from the automated git pull/push scripts:
To shut all of them up, without uninstalling the credentials manager as mentioned in some answers here: https://stackoverflow.com/questions/37182847/how-do-i-disable-git-credential-manager-for-windows, here's what now works, sitting on top of the automated (bash) shell scripts:
# https://serverfault.com/questions/544156/git-clone-fail-instead-of-prompting-for-credentials
export GIT_TERMINAL_PROMPT=0
# next env var doesn't help...
export GIT_SSH_COMMAND='ssh -oBatchMode=yes'
# these should shut up git asking, but only partly: the X-windows-like dialog doesn't pop up no more, but ...
export GIT_ASKPASS=echo
export SSH_ASKPASS=echo
# We needed to find *THIS* to shut up the bloody git-for-windows credential manager:
# https://stackoverflow.com/questions/37182847/how-do-i-disable-git-credential-manager-for-windows#answer-45513654
export GCM_INTERACTIVE=never
git config credential.modalprompt false -- mentioned as a solution in answers to that linked SO question. no dice for me.GIT_SSH_COMMAND environment variable: nothing worked but keeping it as I suspect it'll kick in when running this stuff on a Linux box instead of Windows.GIT_TERMINAL_PROMPT=0: no worky either. Kept it in for the same reason, but no dice on Windows.Oh, and uninstalling the git credentials manager as suggested in other answers in that SO link was decided a no go option as it would definitely impact other repository trees where this thing may be useful one day. Though it was considered for a bit, before I decided against doing this.
*_ASKPASS env.vars., oddly enough shut up the 'X-Windows looking' login prompt on (automated) git push. Yay!GCM_INTERACTIVE=never was the magic ingredient to finally shut up that git-for-windows credential manager dialog. Thanks to that particular answer (https://stackoverflow.com/questions/37182847/how-do-i-disable-git-credential-manager-for-windows#answer-45513654), which isn't near the top of the list, but definitely was the most important one for my case.$ git --version
git version 2.30.1.windows.1
<rant> Been looking for this info on-and-off for years: this time apparently I was lucky and maybe persevered longer(?), wading through the zillion pages yakking about setting up your credentials: google clearly is not intelligent. At least it does not listen very well to minority questions, that's for sure. </rant>
The title is added in hopes that google indexing places this page higher for the next one looking for answers to these questions or variations therefor...
If you are using ssh authentication, and on linux, then you can create an ssh command replacement to disable this.
Create a file called "sshnoprompt.sh" with:
ssh -oBatchMode=yes $@
Make this file executable with chmod +x sshnoprompt.sh
Then when starting git:
GIT_SSH="sshnoprompt.sh" git clone foo@dummyserver:not_a_repo
And it will not allow any interactive git prompts or questions - it shouldn't be able to ask the user for anything.
GIT_TERMINAL_PROMPT=0 git clone https://github.com/some/non-existing-repo
Work for me on Mac.
When you only have control over the git configuration:
git config --global credential.helper '!f() { echo quit=1; }; f'
Gives
$ git clone https://github.com/edx/drf-extensions.git/
Cloning into 'drf-extensions'...
fatal: credential helper '!f() { echo quit=1; }; f' told us to quit
The idea comes from the original committer of GIT_TERMINAL_PROMPT after following @user243345's link.
Working from git version 1.8.3.1;
git clone -c core.askPass $echo url/or/path/to/git/repo
The configuration core.askPass works by passing the control of handling credentials to the aforementioned program. However since $echo cant do anything except output, the clone attempt promptly fails and respective bash redirection applies. This code is only invoked in the event that the git repository happens to be private, and will pipe error output stating that authentication failed for the particular repository. You can test this against the https://github.com/git/git public repository against a private repository you know about.
To sweeten the deal, you wouldn't even need to reference a program like echo in the first place. Simply passing git configuration -c core.askPass with no following input would still cause failure in the event the repository happens to be private as the code will not know what program to offload credential handling to. While this is certainly an older and simpler method than the others mentioned here, I do not know if it will have the same effect in older versions of git.
Depending on how you're running git, redirecting stdin or stdout so that they are not connected to terminals will stop git from prompting for details and just cause it to error.
This would also allow you to surface errors (or at least logs) to the webservice.
