SourceTree git authentication against BitBucket only works some of the time.

Well that error message appeared early this morning - setting my work back half an hour before I went into two meetings. Two hours later - without even closing and reopening SourceTree I have attempted to push the commit - and it has worked. I have done absolutely nothing to change the SourceTree set up or the remote repo set up.

That on/off pattern isn't random — it's the brownout schedule. Atlassian is retiring Bitbucket app passwords (CHANGE-3222) with scheduled windows at 00:00, 06:00, 12:00 and 18:00 UTC, and this week they're running about 3 hours each. Inside a window, anything still authenticating with an app password fails with that CHANGE-3222 error; once the window passes, the same setup works again with nothing changed on your end. That's your "appeared this morning, worked two hours later."

So the error is really telling you that something on your machine is still pushing the old app password, even though SourceTree shows your token connected — the brownout only makes it visible on a schedule instead of constantly. It stops being intermittent on July 28, when app passwords are removed for good.

Either way, clear that stale credential now: remove the bitbucket.org entry from your OS credential store (Keychain, Windows Credential Manager, or your git credential helper), and check git remote -v for an https URL with a username baked in. Once only the API token is in play, the brownouts won't touch you.

Why the hell would you do that - to really annoy your customers - just turn it off!

.

That's exactly it. Git over HTTPS asks a git credential helper for credentials, not SourceTree, and on Windows that helper is the Git Credential Manager. So even with SourceTree emptied and no Windows Credential Manager entry, git's own helper config still kicks in and hands over whatever it has cached, which is why a pull errors instead of prompting you to set up auth.

The SourceTree checkbox is unreliable because it only affects SourceTree's Embedded Git. If SourceTree is set to System Git (Tools > Options > Git), that toggle doesn't touch your system git's helper at all.

To see what's actually configured, run this in the repo:

git config --show-origin --get-all credential.helper

That prints every credential.helper line and which config file it lives in (system, global, or repo). You'll likely see helper = manager or manager-core. To stop git reaching for the cached credential, clear that helper:

git config --global --unset-all credential.helper

(or edit the file it named and delete the helper line). Then the next pull prompts fresh, and you enter x-bitbucket-api-token-auth as the username with your API token as the password.

To keep a helper but drop only the stale entry, GCM stores it under git:https://bitbucket.org, so erasing that one does it: printf "protocol=https\nhost=bitbucket.org\n\n" | git credential-manager erase.

Re the tick box. I am using the embedded git but it has no effect.

Now the problem is that uninstalling sourcetree still leaves all sorts of git config files lying around and so when you reinstall it it just picks up where you left off.

I haven't installed another version of git anywhere.

This is just consuming so much time and that ridiculous brown out policy just increases the amount of time between testing.

That leftover-config thing is the actual root of it, and you don't have to hunt for the files by hand. Git will name them for you. Run this in a repo:

git config --show-origin --get-all credential.helper

Each line comes back prefixed with the exact file it's read from, something like file:C:/Users/you/.gitconfig or a path under the embedded git. That's your list of the config files lying around. Your global ~/.gitconfig (C:\Users\<you>.gitconfig) is the one that survives every SourceTree uninstall, so a stale helper = manager sitting there is why a reinstall carries on where it left off.

Once you see which file holds it, clear it:

git config --global --unset-all credential.helper

or open the file it named and delete the helper line. After that the next pull actually prompts instead of silently replaying the cached credential, and you put x-bitbucket-api-token-auth as the username with the API token as the password.

On the embedded-git checkbox doing nothing: even on Embedded Git it only stops SourceTree's own helper. It can't strip a helper line already written into your global config, so the config edit above is what actually settles it.

And yeah, the brownout makes this miserable to debug because your test either works or doesn't depending on the window. The one upside is it ends for good on 28 July, so this stops being a moving target soon.

Thanks for your time but.......The gitconfig your commands list out has nothing in it - so again sourcetree is going off somewhere else to get details. I must be using embedded git as there is no git in any PATH variable - typing git on the command line gives nothing. Does the embedded git come with the utility that uninstalls git from the command line? Cant remember what its called. I just want to remove any trace of git and sourcetree from my machine, delete my local repos. Then re install clean sourcetree and clone the remotes using SourceTree with OAuth. Or just swap over to GitHub would have been quicker.

There's no separate git uninstaller to hunt down, and that's the clue itself. The embedded git isn't a Windows program, it's a folder inside SourceTree's app data, which is why git on the command line finds nothing and why the config came back empty. Nothing to uninstall, you delete the folder and it's gone.

For a clean wipe: uninstall SourceTree from Add/Remove Programs, then in C:\Users\<you>\AppData\Local\Atlassian delete the whole SourceTree folder (the embedded git lives under it in git_local), and delete the SourceTree and SourceTree-Settings folders in AppData\Local too. Then delete C:\Users\<you>.gitconfig, and in Windows Credential Manager remove any leftover git:https or bitbucket.org entries.

Then reinstall and go straight to OAuth. That's the bit that makes it stick, since OAuth doesn't use a credential helper at all. SourceTree holds the token itself, so there's nothing cached to fall back on and none of the worked-an-hour-ago behaviour.

And yeah, given how much time this has eaten, nobody would blame you for the GitHub Desktop route either.