The original issues were that during an interactive rebase when Sourcetree calls it's internal text editor to continue the rebase (1) the editor is not populated with the change history and (2) on selecting OK Sourcetree generates a pop stating "Oh noes ". On trying to continue the rebase the repository is clearly in a weird state and you are prevented from completing the rebase.

Issue (1) and (2) are present in Sourcetree 3.4.24 but resolved in 3.4.27. The editor is now populated with the change history and on selecting OK the rebase appears to continue.

However, there is now a third (3) issue that is the focus of this bug report. When continuing the rebase the editor in Sourcetree, or Sourcetree itself, does not release the lock on the repository preventing any further conflicts from being resolved. In our case, using external merge tools.

This can be partially worked around by deleting the lock file, but that may cause additional issues.

The workaround for our team has been to create a custom command that replaces the command Sourcetree issues when continuing a rebase from "" to "git rebase --continue". This avoids calling the problematic editor and there is no longer a lock on the repository.