Submodule with different user fails to clone/push with Sourcetree

Eric Coetzee January 17, 2013

I moved a number of working copy Hg repositories (all bitbucket) from old to a new machine. Installed Sourcetree on new machine and added repositories to new Sourcetree.

All work fine locally on all repos. However, 2 of the repos fail to push to bitbucket. The 2 which fail, are the only 2 that have submodules which are owned by a different user than the parent repo. I continuously get prompted for the password of the main repo, even though the 'save in keychain' checkbox is checked. I then cancel and the push fails with "abort: authorization failed" in text output window.

When I try to clone these 2 repos using my new configuration, I get prompted for the password of the parent user twice. It then fails with the message "abort: destination '/Users/...../.../.. etc. ' is not empty" in the text output window.

Inspecting the new folder, I see that some files are there (e.g. .hg etc) but no working files.

All the repos work fine on my old machine, including the 2 with different users for main and submodule.

OSX 10.8.2

Sourcetree version 1.5.7.1 (1.5.7.1)

8 answers

1 accepted

1 vote
Answer accepted
stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 17, 2013

The reason is probably that you're using HTTPS as the authentication mechanism and the URL doesn't include the user name, so SourceTree doesn't know what user to use to automatically look up your password with.

When you use HTTPS, SourceTree needs both the username and the hostname to figure out the password to retrieve from the keychain (you can't do it without knowing the user up-front). If you don't specify that in the URL, for example https://bitbucket.org/owner/repo rather than https://user@bitbucket.org/owner/repo then SourceTree has to either prompt you for the user, or guess. By default, it guesses with the default username for that host (in this case Bitbucket.org). The defaults are actually available to you to view/edit in Preferences > Network - we set them up from the last successful manual login. If that fails, it has to prompt you, and that's why you're getting those prompts because its first guess is not correct. This is why I always advise people to use the user@ prefix on HTTPS repos which need authentication, it's more explicit.

Now, while using the user@ prefix in main clone URLs to resolve this ambiguity is fine, in subrepositories it gets a bit trickier - you can't really put an authenticated user in the URL, since each person cloning will actually get the same URL and they probably use different users.

Therefore, the real answer to this is that you need to be using SSH URLs for subrepos which require authentication. Only use HTTPS for subrepos which are public. Either that, or you have to edit the subrepo URL locally to add your username prefix.

HTH

Eric Coetzee January 17, 2013

Steve,

Thanks for your response. Both the parent and it's submodule have the user explicitly in the URL. i.e.

https://usera@bitbucket.org/usera/sharedmodules

https://userb@bitbucket.org/userb/parentproject

(not live links - examples only)

I assumed it would prompt (or get from keychain) the password for each repo.

Btw, i tried again with Sourcetree 1.5.6 on old machine and had no problem pushing and cloning.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 17, 2013

Hmm, that's strange then. I don't believe anything changed in 1.5.7, it might just be an issue with the keychain contents somehow. Can you check Keychain Access and look for the user & domain in question, and check the password stored there?

BTW after editing or doing something else in Keychain Access, please close Keychain Access and leave it at least a minute or two before trying in SourceTree. Keychain Access can actually lock the keychain entries for a minute or so, especially if you check the 'Show Password' box, and this can actually cause the keychain lookup to fail in SourceTree (one case where debugging the problem can often cause it's own problems!)

Eric Coetzee January 18, 2013

Did some tests to see if the keychain access works. Closed Keychain Access each test - as you suggested.

Test repos used and user which requires access:

- sharedmodules [usera access]

- parentprojectA (has sharedmodules as submodule) [usera access]

- parentprojectB (has sharedmodules as submodule) [userb access]

Test A

1) Erase all bitbucket passwords from keychain

2) Pull sharedmodules repo

Result: Sourcetree propted for usera password and keychain entry was created for usera on bitbucket

Test B

1) Pull parentprojectA

2) Push a change to parentprojectA

Result: Sourcetree did not prompt for password (as it's already in keychain after test A) and successfully pulled and pushed

Test C

1) Check outgoing changes for parentprojectB

2) Click Cancel after outgoing changes were listed

Result: Sourcetree prompted for userb password and keychain entry was created for userb on bitbucket

Test D

1) Close Sourcetree and start again (in case information is cached - I don't know)

2) Check outgoing changes for parentprojectB

3) Click OK after outgoing changes were listed

Result: Sourcetree did not prompt for password at step 2 and correctly listed outgoing changes. Proving it used the keychain entry created in test C. After clicking 'OK' in step 3, Sourcetree prompted for userb password again. After entering password, output showed the following text and then prompted again for userb password. After this the keychain entry for userb, which was added in test C, is now removed.

password:password:abort: authorization failed

pushing to https://userb@bitbucket.org/userb/parentprojectB

http authorization required

realm: Bitbucket.org HTTP

user: userb

pushing subrepo shared to https://usera@bitbucket.org/usera/sharedmodules

http authorization required

realm: Bitbucket.org HTTP

user: userb

password:

Eric Coetzee January 20, 2013

Steve, another test I did to check that the repo is still ok, was to copy the repo back onto my old machine (OS X 10.6 - Sourcetree 1.5.6). From there I could push successfully without a problem.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 20, 2013

Thanks for the testing. FWIW, SourceTree basically responds to whatever hg prompts for and turns that into either a keychain lookup or a prompt depending on the circumstances. In the case of an authentication failure, the keychain item is removed in order to make sure we don't try it again and prompt you in the first instance instead.

Looking at the output from Test D, I'm a little confused by this bit:

pushing subrepo shared to https://usera@bitbucket.org/usera/sharedmodules

http authorization required

realm: Bitbucket.org HTTP

user: userb

The issue being that hg is prompting for 'userb' when the URL says 'usera' (at least, I assume the username is pre-completed, that's what hg usually does when given a URL with the user@ prefix). When SourceTree sees this, it will try the password for userb@bitbucket.org, and presumably that will fail if the authenticated user for that subrepo is supposed to be 'usera'. ST doesn't know why, so it will assume the worst and remove the one it tried from the keychain ('userb'), causing another prompt next time.

I'm also confused as to why your other machine is working, becuase I'm pretty sure nothing in this area was changed in 1.5.7. The URLs for downloading each version are:

1.5.6: http://downloads.atlassian.com/software/sourcetree/SourceTree_1.5.6.dmg

1.5.7: http://downloads.atlassian.com/software/sourcetree/SourceTree_1.5.7.dmg

If possible, could you try both versions on the same machine (either way around) to isolate whether it's the machine or the version?

Eric Coetzee January 21, 2013

Steve, i see now I messed up when i renamed the user usernames to post them in the comment. The second "user: " line does say "usera" - so it matches the URL. Apologies for confusing the issue. But the UI still only prompts for the password of only one user (i.e. not both); that is it prompts for parent repo user (userb in our case). Anyhow, I now understand why the keychain entry is removed. So, if I understand correctly, then the question is why the Hg authentication fails.

Does ST 1.5.7 use a different version of Hg than 1.5.6?

I will try the 2 downloads later today and let you know.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 21, 2013

Ah OK, thanks.

No, the embedded version of Hg is the same in 1.5.6 and 1.5.7, it could only be different if you had chosen to use the system hg in Preferences > Mercurial on one or other machine.

Eric Coetzee January 21, 2013

Thanks Steve, I see the internal is v2.2.2.

Although I have not yet had a chance to install the 2 versions on one machine, it might be worth mentioning that the command line Hg I use as fallback (Hg 2.4.2 on OS X 10.8) pushes fine.

It prompts for 'userb' password (parent repo) and then for 'usera' (for submodule).

Eric Coetzee January 22, 2013

It's not specific to Sourcetree version 1.5.7. I see exactly the same behaviour with 1.5.6 on the new MBP running mountain lion and 1.5.7 works fine on my old MBP running snow leopard. In all cases ST was configured to use the internal Hg (v2.2.2).

Any other ideas?

Eric Coetzee January 24, 2013

Is there anything else I can do test further so we can identify what might be causing the auth failure?

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 24, 2013

I'm drawing a bit of a blank here now, I haven't been able to recreate it yet and it sounds like some subtle difference in the Mountain Lion keychain access somehow. Are you up to date with the latest 10.8?

The way to guarantee this isn't a problem in future is to use SSH keys rather than manual login via HTTPS - I realise that's not a solution but it is a solid workaround.

1 vote
Phillip Molaro May 12, 2014

For what its worth, I had this same probelm in previous versions, then one of the updates seemed to have fixed it.

However, with the latest release (Version 1.9.2), the issues seems to have returned. When I do a pull or a push to origin, I am now asked twice to enter my bitbucket password. We do use https and we do include the username in the url. If it is helpful to know, I am getting this when I interact with shared projects. I already had a BitBucket account, so my company just shares their repos with my account.

Here is the specific error I am getting:

2014-05-13 09:15:01.582 git-credential-sourcetree[82214:507] Error (internetKeychainItemForServer:withUsername:path:port:protocol:) - The specified item could not be found in the keychain.
From https://bitbucket.org/mycompanyname/repo-name

Here is the URL format for the repo that generated this error (although all my company ones look like this and have the issue now):

https://myusername@bitbucket.org/mycompany/repo-name.git

Finally, I am on Mac OSX 10.9.2

0 votes
Edwin Boersma May 4, 2016

I'm having the same issue on my MacBook, while it works as expected on my iMac. My colleague gets prompted on his iMac. We all run OSX El Capitan.

Have compared the repo settings and they are the same. No differences in capitalization. In the keychain entry, the user and password are correct. Removed the entry from the keychain and pulled again. Got prompted twice for the password.

Then I created a new user in the Bitbucket Server. No luck here, I got prompted for the password twice again.

So, it seems to me that it is not the keychain, although one cannot be too sure. Maybe SourceTree doesn't send the password? On other threads, I read about issues with ssh-agent. I didnt manage to solve it through that either.

How can the login process be monitored? Can it be run from the console?

Note: using SSH keys will (of course) work. 

0 votes
thinsoldier
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 7, 2014

Anyone found a fix for this yet?

The error I'm getting is:

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree submodule add -f https://thinsoldier@bitbucket.org/thinsoldier/rex-public.gitrex
Cloning into 'rex'...
warning: templates not found /usr/local/git/share/git-core/templates
fatal: could not read Password for 'https://thinsoldier@bitbucket.org': Device not configured
Clone of 'https://thinsoldier@bitbucket.org/thinsoldier/rex-public.git' into submodule path 'rex' failed
Completed with errors, see above

I am the owner of all 4 repositories in question. The main repo and the 3 other repos I want to have as submodules. I can set up bookmarks and pull all 4 repos separately. But can't use them as submodules.

I seem to only have this problem with bitbucket repos. I can successfully use github repos as submodules. It doesn't matter if it belongs to me or not. If it's on git hub, I can use it as a submodule. But I can't use any from bitbucket.

thinsoldier
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 7, 2014

When I add a submodule directly from the command line it asks for my password, then it downloads the files from the new submodule. No problems.

My sourcetree is using Embedded Git version 1.8.4.2

My system git is /usr/bin/git and is version git version 1.8.5.2 (Apple Git-48)

Sourcetree Version 1.9.7 (1.9.7)

0 votes
Tyler B [Atlassian]
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 9, 2014

The answer I found when I stumbled upon this issue was found here:

http://stackoverflow.com/questions/20217389/sourcetree-cant-push-to-bitbucket

In short: I didnt have write access to the repo.

Eric Coetzee June 9, 2014

I certainly do have access to both repos. See my comment that hg command line works fine. The command line prompts for each password in turn.

0 votes
CarlosAlvarez June 5, 2014

me too, with the lastes release(1.9.2) have the same problem as you

0 votes
Acacio de Barros May 28, 2014

Phillip Molaro, I'm having the same problems as you (correct URL with username). I'm also using OSX 10.9, though my subversion is 10.9.3.

0 votes
Eric Coetzee January 17, 2013

Some more information when I try to push to bitbucket; the console log shows the following message twice before prompting for the password of ONLY the parent repo.

SourceTree[48351]: Error (internetKeychainItemForServer:withUsername:path:port:protocol:) - The specified item could not be found in the keychain.

After entering password, Sourcetree tries to authenticate (cert warnings appear in Sourcetree output) and then repeats to write error message twice and promt for parent repo pwd.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events