Background pull request merge should use default merge strategy

I am currently using Bitbucket Server 4.7.1 and git 2.8. In this version of Bitbucket Server pull requests are being blocked by certain submodule modifications that git can't handle when using the no fast forward strategy.

Example:

Let's say I create a submodule in a repo on the master branch and then in a later commit use the git mv command to move that submodule to a different file path. If I then attempt to merge my moved submodule via pull request into the master branch the pull request will be blocked saying that there is a merge conflict. This is because the background merge uses the no-ff option when computing the trial merge. If I perform the merge locally, git elects to use a fast forward merge strategy and the merge is able to complete successfully. In other words, using the --no-ff option is causing the merge with the submodule change to fail. The workaround is to perform the merge locally and then push to the target branch, effectively ruining our pull request only workflow.

In Bitbucket Server 4.9 the merge strategy capabilities have been updated to allow a user to choose which merge strategy to use when performing the merge. This makes it possible to use the fast forward strategy when merging a pull request with an above described submodule change and merge the pull request successfully. However, and here is the suggestion for future improvement, the background trial merge does not use the default merge strategy defined for the repository. This means that even though the default merge strategy is fast forward, the user will see a message like Bitbucket Server could not create the merge diff for this pull request because the background merge still uses the --no-ff strategy and now the user will have to bravely attempt the merge not sure if it will succeed or if they're doing the right thing. I think it would be great if the default merge strategy was the one used for the background merge. If would also be nice if git could handle submodule moves in a non-fast forward fashion but I'll take that up with the git people themselves.

Edit: there seems to be a bug in JIRA that isn't letting me type --no-ff easily, fyi.