![]() You will try, and think you are not successful, but you are really near from it ! follow with me: ![]() I can use this to add my repos as remotes and my old, carry-over authentication still works for old repos. It popped up a login field I entered my email as user name and the PAT password as my password and after a while it came back Authenticated. The only flaky part was actually clicking the button to activate the Personal Access Token I had to make sure the Host URL field didn't have focus (I clicked every field in order, top to bottom to make the PAT button work). I added a new account to Authentication and used the built-in Azure option and the ` ` URL for the Host. The Azure integration seems to be working okay now. If, like me, you regenerated your token you use for SourceTree so you could get the password, you will need to edit the DevOps remotes and select the new DevOps Host entry instead of the old Generic Host. Remotes will work fine with the format after this initial account authorization.Īny remote repository added using the old Generic Account / Generic Host method (3.1.3 on Windows still had no DevOps integration) should still work if you didn't regenerate the token those remotes use. When trying to authorize with, it seems to succeed in logging in, but fail at gaining Git permissions. This is still the case in the SourceTree 3.2.0 Windows beta that is only a few days old. ![]() There is an open bug report on it (as Christian Wölke pointed out quite some time ago) that seems to be getting some slow progress, but a bump could help reminding them that it's still an active issue: When using this as host URL, and then using the account name used to log in DevOps as username and the PAT as password, it's working.Įdit:As of the issue is still ongoing, and I see more people are finding the answer here. One should still write it in the old VSTS link format (even if the organization has been made on DevOps): ![]() Please give this a go, before trying the workaround!Īpparently (at the time of writing ), when writing the host URL rather than writing: This has the effect of re-defining the 'git:' credentials in the Windows Credential Manager, but also sets 'hg:' credentials for use with Mercurial and 'sourcetree' credentials for use when calling REST APIs.įrom the sound of it, your 'git:' credentials are correct, you can interacts with your Bitbucket repository via git, but the REST ones are out of sync, hence the red X in the remotes tab.Edit: (as of ) The issue is reported as resolved - see In the Sourcetree Tools/Options/Authentication tab it is possible add a Sourcetree account for Bitbucket. When Sourcetree acts on a repository it asks git to do all the work and git will retrieve any suitable credentials from the Windows Credential Manager, so Sourcetree effectively can pull/fetch/push etc without prompting for additional credentials. If these credentials are valid it will store them in the Windows Credential Manager, prefixed with 'git:' Ignoring Sourcetree for a second if you know the remote HTTPS URL to a private Bitbucket repository and try to clone it via the git command line, git will prompt you for a username/password. Sourcetree effectively deals with 2 types of credentials, git/hg ones and REST ones, although they contain the same information.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |