Issue fixed in 4.2.5. Kindly upgrade the Sourcetree Version and verify.

It’s not my report.

You are right, but that's not relevant. What I was trying to say is: This report is a duplicate of SRCTREE-2674 and will probably be closed as a duplicate. If you or anyone else here want to be part of that solution, please move your discussions there. If you keep your discussions here, they will most likely be ignored while the rest of us looks for a better solution over there.

It’s not my report.

Why does SourceTree need to block on an external process at all?

Taking a wild guess, I'd say because it needs to perform clean up once the merge is done, as to run an external merge, it must create temporarily files (a 3 way merge needs 3 files and only one of these is in your directory tree when you start the merge, the other two, the base file and the alternate version, must first be pulled out of the repo and then a 4th back up file is created in case the merge goes horribly wrong) and these temporarily files would be shown as ugly untracked files in your file list during the merge if the UI was not blocking. This may confuse users, having no idea what these files are good for, possibly filing bug reports or just deleting them, which may have other negative consequence, cause malfunction or break SourceTree in some way or accidentally causing these files to be added and comitted to the repo. I'm not a developer of the app, I cannot tell you the exact reason, but I see hundreds of things that might go wrong if you they wouldn't block.

However, please take your discussions over to SRCTREE-2674, which is an already verified issue and an exact duplicate of your report and where people are already discussing alternatives and caveats.

Why does SourceTree need to block on an external process at all? It seems to update its view of the monitored files asynchronously when editing files in any other external editor and it doesn't need to know anything about the state of the external merge. This is an ancient issue and I don't even know if the current version of SourceTree is affected.

SourceTree needs to know when you are done with "merging". When you start an external process, the only information that you as parent process are guaranteed to receive is the information that your child process has just died, as well as its exit code. Thus SourceTree waits until the process has died, knowing for sure that you are done merging when this happens, and to prevent any data race conditions, it blocks until this has happened.

How else would you like SourceTree to work?

Unblock when you close the FileMerge window? SourceTree won't be informed when you close that window. Monitoring windows of another process is not easily possible (SourceTree would have to register as an Accessibility Helper process, requiring the user to authenticate SourceTree for this task and then using the Accessibility API it would be possible to retrieve a list of Windows from another process, albeit still very complex).

Monitoring the merged file for changes? Just because you hit CMD-S and FileMerge and save the current merge output doesn't mean you are done merging, as you can still make changes and hit CMD-S again. SourcTree cannot continue until it knows for sure that you are done and monitoring the file for changes simply won't tell it whether you are done or not.

I can confirm this observation.
Open an external diff process and manage file compare.
Closing FileMerge window with ⌘-W causes SourceTree to beach ball but closing with ⌘-Q allows SourceTree to continue.
It would appear that SourceTree is waiting for FileMerge process to return 0.

The only workaround I have found so far is to always ⌘-Q FileMerge or any external diff tool when finished.

I recognized that SourceTree does stop reacting only when I close the FileMerge window and do not quit FileMerge. When I instead quit FileMerge completely, SourceTree works as it should.