Force detection of specific repository type when connecting to Kiln repository over SSH

I'm using SourceTree on Windows to connect to a repository hosted on KilnHG.comand my connections are over SSH.

Kiln, as you may be aware, allows repositories to exist as both Git and Mercurial repositories.

When Kiln shows the SSH URI to use to clone the repository, this URI does not change between Git or Mercurial versions of the repo. (Strangely, when accessing the repo over HTTPS, the URI does change - The Git version has ".git" at the end of the URI whereas the Hg version has nothing).

When I enter the SSH URI into SourceTree's "Clone Repository" dialog, SourceTree attempts to detect the repository type. This always comes back with the Git Repository, never the Mercurial one.

As far as I know, there's no way to override SourceTree's behaviour here and tell it to clone the Mercurial version instead.

Is there any way I can force SourceTree to clone the Mercurial Repository or otherwise override SourceTree's "detection" of the repository type?

(For the record, if I use hg or git from the command line with the same SSH URI, I can successfully clone the correct repository of the correct type).

1 answer

1 accepted

0 votes
Accepted answer

Hmm, when I reviewed Kiln's dual git/hg features I thought we were OK because of the .git extension (SourceTree actually cheats if it sees the .git suffix and short-circuits the normal probing). Perhaps it's changed since I last tried it but it sounds like now the non-.git suffixed URL reports success for both 'hg id' and 'git ls-remote', which would explain why it's identifying as git. We parallelise the probe requests, but git tends to be marginally faster than hg so it will win.

Since this is so specific to Kiln it's unlikely that we'd put a force optino in here just for this case (our designer is being strict about not adding new controls unless needed), all I can really suggest is that you do the initial clone on the command line. Sucks I know, but this is such an edge case I'm not sure we can justify anything more.

Thanks for the answer Steve. Your suggested workaround is exactly what I've been doing so far. I appreciate that this is currently a fairly edge case and I also understand your designer's reluctance to add further buttons and controls to the already fairly busy (but necessary) UI. Just glad to know I'm not overlooking something obvious.

I don't know how it works under the hood, but maybe Atlassian could resolve it by adding Kiln to the hosted repositories list and doing setting that configuration to try Hg first.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Oct 23, 2018 in Sourcetree

Tip from the team: configure your repos for hosting goodness!

Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...

960 views 4 2
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you