Workspace repo listing issue

Issue Summary

I'm just setting up a new M1 and also getting an empty repository list on 1 out of 3 accounts (so far). It is the first account added that's empty, and all use Google authentication to Bitbucket FWIW.

The first account also defaulted to HTTPS, the others are SSH.

UPDATE: It's repositories in other workspaces that are the problem - personal workspaces are working fine.

Other issues (presumably not just because of M1 silicon, but changes in v4.1.6-beta:

• Incorrect URL when cloning an account repo in a multi-account setup (bitbucket.org is used instead of the SSH alias created by SourceTree)

• "This is not a valid source URL" is shown even when the URL is corrected (and works on the command line)
• Empty details window when clicking on the above error, so I'm unable to determine why SourceTree thinks the URL is invalid

==========================================

Raul, as it turns out the same accounts are missing from other workspaces in 4.1.5 as well (native Intel) as well. I don't recall the last time I looked at this screen.

I also see the incorrect URL when cloning in v4.1.5. This is on a machine that I've grandfathered in over the years - before you had multi-account support - and put the issue down to this (I'm setting up my M1 completely fresh).

The log output when clicking "This is not a valid source URL" is different behavior - works in 4.1.5, empty in 4.1.6

=========================================

So I checked out some repos via vscode and add the folders to SourceTree. Nothing worked - opening a repo I got 'git log' failed with code -1, 'git status failed' etc.

The problem seems to be with SourceTree using its embedded git - when I switched to external git (2.32.0), things were working much better - including output log for 'not a valid source URL'.

The source URLs still don't work when using multiple accounts, but that's not specific to this beta / M1 silicon.

Steps to Reproduce

-NA

Expected Results

-NA

Actual Results

The below exception is thrown in the xxxxxxx.log file:

...

Workaround

-NA