Sourcetree: Fatal: could not read Password for 'https://username@bitbucket.org': Device not configur

I’ve been experiencing this issue for over a year. Atlassian can’t seem to fix it though they try. I’ve spent hours and hours trying to troubleshoot this. I posted this summary on the Atlassian forum. I’ve edited this to make it relevant to this audience. This is the error Sourcetree is throwing when using the Gitflow system but only when finishing a Feature or a Release:

Fatal: could not read Password for ‘https://username@bitbucket.org’: Device not configured

[quote]I’m developing Win/Mac apps on a Mac with Sourcetree v3.2.1 for source code control. This has been a mess for over a year.

I’m using Gitflow. I have no problems committing when on development branch. I have problems finishing features and releases. I’m spending hours on this.

First, what device is not configured?

In the Sourcetree preferences what should the “Auth Type” be set to? There’s 2 choices: Basic and OAuth. What should the protocol be? There’s 2 choices: HTTPS or SSH.

For a time, in the Repository Settings, I could add my password as such.

https://username:password@bitbucket.org/username/repo.git

That no longer works.[/quote]

This is the error users report getting:
I had liked using Sourcetree with a Bitbucket account. I’m a single developer. I develop on an iMac. I could clone to my Windows 10 machine and work there, make changes, and commit. I could also clone to my MacBook and work while on the road, make changes, and commit. I liked how it kept my code in sync on 3 machines. I always build on my iMac as I’ve got Mac codesigning there. I copy over to the Windows machine for codesigning for that platform. It’s been nice until just over a year ago.

Now it’s a mess. Huge time loss, delayed delivery, and code becoming totally screwed up. It’s so bad I make binary backups so I can start over.

I’m not alone with this experience, others are reporting it. I’m wondering if anyone here has any experience with this and maybe even a solution.

Thanks!

Duane Mitchell

My personal recommendation, having had growing pains with a few different clients, is to drop SourceTree. It’s garbage.

I use Fork. It’s free. It’s clean. It’s xplat. It’s native. https://fork.dev

I only have one tiny issue with it right now… The diff chunk highlight is far too big to be useful in this build. I’m not sure if it’s a permanent change or a bug. We’ll see.

@Tim:
The photo on the shared link is a real pain for my brain :frowning:
This does not let me think this is an easy to use software at all :wink:
Thanks for the share.

for a small team (ie < 10 people) that doesnt have lots of branches SVN may be much simpler

remember that Git was created By linux for dealing with the huge # of branches etc that the Linux kernel often had going, huge teams, etc

I doubt there are many of us that need that level of complexity

(This should really be moved to Off-Topic.)

Mac or other? If Mac, look in Keychain Access and see if any of your certificates are expired in any keychains, especially System Roots. If so, delete them. Expired certificates can cause all sorts of weird, otherwise-unexplained problems.

Interesting… I just went to sourcetree to see how I have my Bitbucket configured and I got an error… Did the OAuth routine and got an error. Sourcetree then complained with http 404 error. I then refreshed sourcetree and my repos showed up without error. I have it configured for basic auth over https… Never had any problems with Github or Gitlab via Sourcetree.

Downloaded it. Looks good to me.

Sourcetree is/was a fairly easy to use interface IMHO. But I only work for myself so I have control over what is on each of my 3 machines.

@Kem Tekinay as I mentioned I’m working on a Mac but need to move over to my Windows machine sometimes, make changes, and commit. I’ll look at the certs in Keychain.

I have an update! My issue with Fork was related to a setting I changed somehow at some point. They even answered me on twitter. Great app.

I believe that this discussion is a great example of a major issue with the selection of any versioning system - what a team of 3,000 (Linux kernel?) needs versus what a team of 1-5 needs is very different. I’ve used CVS since the beginning of time (RCS before that) and I still use it today on our C and ASM code - not because it’s better, but because it’s what I know and it has very good integration with C and ASM files. We went to SubVersion (SVN) for Python and Java work, then tried Mercurial (HG) and then went back to SVN. Later, I took a look at GIT, but the learning curve in moving from what we know was too steep to justify any perceived “better-ness”.

Today we use CVS for C/ASM, and SVN for everything else (including my Xojo work).

It’s nice to have the perspective of other users of other systems. I don’t doubt your experiences. I started with Git a number of years ago. Learned it. Sat in on the Xojo webinar about it. I had a great system going for my needs. Didn’t find it complicated at all though I did have to invest some time to learn it. Then this bug got into the system that they can’t seem to fix. It looks like that with Fork I can keep my same system going. As always the other systems interest me but I just don’t have the bandwidth to take them on.