Connect by git instead of Hg

[AndreasK]

Hey there,

we have set up a mercurial repository which works fine when used from command line or other hg clients from Mac, Linux and Windows.

Somehow SourceTree tries to connect to the hg repo by using the git commands, which obviously fails. Any hints on how to prevent this behaviour?

Cheers,

Andreas

[AndreasK · Accepted solution]

https://jira.atlassian.com/browse/SRCTREE-914

Thanks again!

[stevestreeting]

Hmm, that's odd - what SourceTree does when you give it a URL is to check out what type of repo it is. Basically, it fires commands at it and checks what works: 'git ls-remote' and 'hg identify' to be specific. This has always worked in my experience.

Unless however, you mean that you've added a local repo? If the local repo has both .git and .hg subfolders, ie it has both git and mercurial repositories within it, SourceTree will pick the git one. We don't support co-located repositories. If the git repo is there by accident, deleting the .git folder will fix it. Other tools work because they're only looking for hg so would not notice if you had a git repo in there too.

[AndreasK]

Ok, I tried hg identify on the repositoriy and it is working from the command line. We use SSL authorization, but SourceTree never aks for a user or a pw. Currently, the certificate is currently not verified which results in some warnings. Can SourceTree handle these warnings?

I created a test repo with a test user with the exact same behaviour. Can I send you the details?

Thanks for your quick support!

[AndreasK]

Unfortunately our admins will freak out, if I post our link online -.- Is there a way to share the url and stuff just with you developers?

[stevestreeting]

Yes, SourceTree can handle warnings.

Please send a reproduction example if you have one, you can either post a link here or log a case at https://jira.atlassian.com and attach it.

[stevestreeting]

Yes, if you create an issue on https://jira.atlassian.com, you can set the security level to 'Reporters and Developers', which means the issue can only be seen by you and Atlassian. But if you have a test repo with a test user which doesn't include any information you don't want to share, that would be even better.