SrcTree can soft lock when using subrepos

Sourcetree appears to treat repos and subrepos separately.  Therefore pulls/pushes from them, which are all really actions on the main repo, can conflict with each other.  This is extremely problematic as a git status on the subrepo can cause a .lock file causing for instance a git rebase of the main repo to fail.

For subrepos, they really need to be treated as the repo that contains them when making calls to the git library or executable.  When any part of a repo with subrepos is busy, all parts of it are busy.

This is also able to have sourcetree put up it's processing blue bar, but I have now had that bar stay in excessive of 8 hours (pushed commit, went to bed) without ever completing.  This only occurs on repos with subrepos.  Only sourcetree is accessing files in that directory.  It's like a subrepo had a lock so the main repo enters waiting but since no main repo tasks were running it waits forever, since nothing tells it that it is done.

It is also possible to do a git pull in a subrepo and have it also lock forever, presumably because another subrepo or the main repo was doing some background refresh when the requested action started, so a lock was seen and it waits for the lock to go away but never gets notified when it does.

Repro steps is to create a repo with large subrepos.  We have binary assets in two subrepos so the main code repo is kept much smaller, but that means we have some huge subrepos.  Sourcetree's processing over the large number and size of files in the subrepo can be slow.  Multiple subrepos make this happen more.  We now have 4 subrepos.  Our other project with just 1 fails with .lock files or sometimes hangs as described here, but much less often.

Often when sourcetree gets confused, the only fix is to close sourcetree and reopen it.  And hope the action you need can be started on next opening before those background processes begin again.

Actions that seem to cause race conditions when using subrepos:
rebase
commit
checkout