After upgrading my client from 1.x to 2.x the Checkout in Sourcetree links in bitbucket don't work.
In Firefox I was able to change the path to sourcetree for the handler to its new location `C:\Users\dneely\AppData\Local\SourceTree\app-126.96.36.199\SourceTree.exe` but other than a wait cursor spinning for a second in the browser nothing happens. (And even if it did work now, won't baking the executable version number into the path mean that I'll need to fix it every time it updates).
Chrome doesn't even do that much, and I can't find a way to change the app association. The only documented solution I could find on how to do so appears to be out of date (or Google is doing something different on Windows) because my `Local State` file doesn't have any text matching `protocol_handler` or any varients of sourcetree that I tried.
Digging into my registry based on one answer I found the following key:
with the value:
> "C:\Users\dneely\AppData\Local\SourceTree\app-188.8.131.52\SourceTree.exe" -url "%1"
The latter is the location that sourcetree installed itself on my computer. Tools-Options-General-Use this version of SourceTree for URI association is checked.
After a pointer from @Hermo Terblanche that a sourcetree process was starting and dieing after a few seconds I went hunting for and found the `\AppData\Local\Atlassian\SourceTree\sourecetree.log` file. Each instance of ST that is spawning and crashing a few seconds later is writing an instance of this into the file.
ERROR [2017-06-12 10:16:29,006]  [SourceTree.App] [OnStartup] - Failed to start System.NullReferenceException: Object reference not set to an instance of an object. at SourceTree.Host.Bitbucket.BitbucketHost.GetCanonicalUri(IConfigurationManager configurationManager) at SourceTree.Host.Bitbucket.BitbucketHost.get_CanonicalUrl() at SourceTree.AppRoot.HandleExtendedIntegrationUrl(Boolean isFirstInstance, String url) at SourceTree.AppRoot.ProcessArguments(Boolean isFirstInstance) at SourceTree.AppRoot.DoWindowStartupTasks() at SourceTree.ViewModel.MainWindowViewModel..ctor(IRepositoryTabContainerViewModel repositoryTabContainerViewModel, ICustomActionsManager customActionsManager, IRepositoryManager repositoryManager, IAnalyticsDataManager analyticsDataManager, ITraceManager traceManager, IDispatcher dispatcher, IAccountManager accountManager, IFailureHandler failureHandler, IDvcsManager dvcsManager, IConfigurationManager configurationManager, IInstanceManager instanceManager, ISchedulerManager schedulerManager, IWebManager webManager, IRepositoryMonitorManager repositoryMonitorManager, ISshKeyManager sshKeyManager, INotificationsManager notificationsManager, IPreferencesManager preferencesManager) at SourceTree.MainWindow..ctor(IRepositoryTabContainerViewModel repositoryTabContainerViewModel, ICustomActionsManager customActionsManager, IRepositoryManager repositoryManager, IAnalyticsDataManager analyticsDataManager, ITraceManager traceManager, IDispatcher dispatcher, IAccountManager accountManager, IFailureHandler failureHandler, IDvcsManager dvcsManager, IConfigurationManager configurationManager, IInstanceManager instanceManager, ISchedulerManager schedulerManager, IWebManager webManager, IRepositoryMonitorManager repositoryMonitorManager, IApplicationManager applicationManager, ISshKeyManager sshKeyManager, INotificationsManager notificationsManager, IBookmarkManager bookmarkManager, IPreferencesManager preferencesManager) at SourceTree.AppRoot.OnStartup(StartupEventArgs e) at SourceTree.App.OnStartup(StartupEventArgs e)
Still not working in 184.108.40.206
Just tried uninstalling, nuking all sourcetree related data I could find from my system and reinstalling. This included:
1. All Sourcetree registry keys.
After doing all of this and reinstalling I still get a second sourcetree prosess spawning for several seconds and then dieing without launching the checkout in sourcetree dialog.
2017/08/11 update. Still broken in 220.127.116.11
Try toggling the setting called: Use this version of SourceTree for URI association
Tools > Options >General
There is a setting "Use this version of SourceTree for URI association" this should be checked.
If it is but the clone from Bitbucket is still not triggering SourceTree, can you try toggling that option off then on again. This should force a re-write of the registry setting needed by Windows.
I stole this answer from Michale Minns.
I just tried that; it was initially checked and unchecking and rechecking it didn't work. I also tried restarting sourcetree after clearing the checkbox and then settting it again in case the setting wasn't immediately written to the registry. The uncheck/recheck states came through, but after being rechecked it still didn't work.
This worked for me. I restarted sourcetree after eachstep (uncheck, restart, check, restart).
Also helpful was trying in I.E.. I got an error dialog complaining about the protocol (hinting that is was having problems linking to the correct app to handle the link).
note: after updating to sourcetree v18.104.22.168 my external compare was broken as well. I had to setup git for the external compare and then it began working again. This was a good fix: https://www.scootersoftware.com/support.php?zz=kb_vcs
painful updates but source tree v2 is so much nicer! worth it.
This worked for me. I unchecked the box and saved. I then went back to options and rechecked the box and saved again. This time, the "Open In Source Tree" box worked. Do NOT try to pick the executable file, that just doesn't work. The "sourcetree" option in the list with no icon seems to be the entry for the app associated with the URI. Unrelated, but why the hell is the app installed under AppData instead of program files like every other windows application? It's not exactly the most secure location for an executable.
Still not fixed in 22.214.171.124
I'm on Windows 10.
The process launched is:
"C:\Users\XXXX\AppData\Local\SourceTree\app-2.4.7\SourceTree.exe" -url "sourcetree://checkoutRef/?ref=
SourceTree starts and then exists immediately. I tried all suggested solutions.
It looks like it's in pre-release or A/B testing at the moment. Not linked on the home page but the notes are up and download link is live.
I've been working on a mac recently so I haven't tested to see if the fix works yet.
I am also experiencing the issue. It seem to only work if SourceTree is already running before you click "Checkout in Sourcetree" from the browser.
If SourceTree is not running before clicking "Checkout in SourceTree", nothing happens. I can momentarily see the SourceTree process starting, but it soon disappears thereafter.
This used to work in v 1.x
I have tried all the workarounds, but believe the issue is not with the registry setting, but the actual exe.
It's not working for me either way. Task manager shows a second sourcetree process spin up if I have it already running, but like the second one in the case where it was already running, it goes away after a few seconds without doing anything.
It's been nearly a month, and I'm getting increasingly frustrated by Atlassian's lack of response. Especially since the security flaws in 1.x mean that I can't downgrade to a working version while they try to figure it out.
I created an interesting workable solution for this bug. It is capable to "Checkout in SourceTree" even when SourceTree is not already running.
The idea is based on a batch file that first launches SourceTree normally, and soon thereafter launches it again with the -url parameter.
Instead of having the original value in the sourcetree/shell/open/command registry key
"C:\Users\<yourname>\AppData\Local\SourceTree\app-126.96.36.199\SourceTree.exe" -url "%1"
you replace the above value with
The content of CheckoutInSourceTree.cmd looks like this:
TIMEOUT /T 1
START sourcetree.exe -url %1
Let me know how this works for you!
This didn't work for me, but since my install is more broken than yours in that checkout in sourcetree doesn't work in both the running and not running cases I didn't expect it to. The only visible impact was that in task manager I now have two ephemeral copies of ST starting and then dying a few seconds later.
Sorry to hear. If you only tested with the batch file you could verify if it still does not work if you start SourceTree manually, wait till it shows the UI, and then see what Checkout in SourceTree does.
You can also increase the timeout in the batch between the two calls to sourcetree.exe. Maybe on slower machines this timeout need to be bigger. I've found that if I completely remove the timeout, it does not work for me either as it does not guarantee that the first call to sourcetree.exe happens before the second.
Having source tree started first does *NOTHING* for me. Until I saw your answer yesterday I didn't know that hitting the open in sourcetree link would ever start the application if it wasn't already running. I always used it with the app launched as part of my startup opening sequence.
Atlassian's well past the point where they've lost all my good will by refusing to publicly acknowlege that there's a lingering problem that can't be fixed by turning it off and back on. They've probably permanently written themselves out of consideration for anything where I get to choose the techstack (vs my employer doing so). As is, I'm only still using sourctree because I've been too busy to try out replacements.
If that afternoon of free time happens before they can be bothered to fix this - or more likely fix it by accident - I'll be gone never to return. Even then I still might leave. None of the 1.x performance fail cases they supposedly flxed ever affected me; and 2.x is constantly decorating itself with wait spinners for things that just worked before a foreverday security bug forced me to downgrade to the newer version of the product.
I had yet another issue after updating to version 2.1.10 today where authentication was broken so I literally couldn't do any operations on the remote repositories.
I've rolled back to 1.9 and everything is working perfectly again including the URI association.
I highly recommend going back to 1.9 :)
1.x has a major unpatched security vulnerability. If it wasn't for that I never would've left 1.10.x. 2.x is garbage even without this bug.
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
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!
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