sourcetree authentication failed after password change

Sourcetree authentication failed after password change how to#
Sourcetree authentication failed after password change code#
Sourcetree authentication failed after password change windows#

Note, the following steps are for Sourcetree for Windows. Some of our users have noted that they fixed the issue by doing the following: This could be related to various things but it could be the case that Sourcetree is still using some older configs that are still using their old account password to authenticate with Bitbucket Cloud when pushing/pulling/etc.

Sourcetree authentication failed after password change windows#

Some Windows Sourcetree users have noted that even after updating their connected account's password to an app password in Sourcetree they still get the same error message. Can you please confirm that you changed this 'new password' to an app password which is different from an account password. You stated that you changed your password for a new one.

However, some of our users prefer to use HTTPS authentication for various reasons. 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.Yes should work as expected given this change had no impact on SSH authentication.

Sourcetree authentication failed after password change code#

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. To sweeten the deal, you wouldn't even need to reference a program like echo in the first place. You can test this against the public repository against a private repository you know about. 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. However since $echo cant do anything except output, the clone attempt promptly fails and respective bash redirection applies. The configuration core.askPass works by passing the control of handling credentials to the aforementioned program. Git clone -c core.askPass $echo url/or/path/to/git/repo 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. At least it does not listen very well to minority questions, that's for sure. 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. Thanks to that particular answer ( ), which isn't near the top of the list, but definitely was the most important one for my case.

GCM_INTERACTIVE=never was the magic ingredient to finally shut up that git-for-windows credential manager dialog.

messing with those two *_ASKPASS env.vars., oddly enough shut up the 'X-Windows looking' login prompt on (automated) git push.

Though it was considered for a bit, before I decided against doing this. 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. Kept it in for the same reason, but no dice on Windows.

GIT_TERMINAL_PROMPT=0: no worky either.

fiddling with that 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.

All the incantations of git config credential.modalprompt false - mentioned as a solution in answers to that linked SO question.

# We needed to find *THIS* to shut up the bloody git-for-windows credential manager: # these should shut up git asking, but only partly: the X-windows-like dialog doesn't pop up no more, but. To shut all of them up, without uninstalling the credentials manager as mentioned in some answers here:, here's what now works, sitting on top of the automated ( bash) shell scripts: # Įxport GIT_SSH_COMMAND='ssh -oBatchMode=yes'

another dialog, which' ancestry has some definitely (crappy looking) X-Windows genes.

git-credentials-manager (developed by the GfW team AFAICT has a clean, grey Windows interface look).

The 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:

Sourcetree authentication failed after password change how to#

How to skip, ignore and/or reject git credentials prompts