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

[CraigTP]

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).

[stevestreeting · Accepted solution]

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.

[CraigTP]

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.

[Seth]

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.