Pull Request resolve conflict instructions are reversed when merging from release branch into feature branch

The instructions to resolve a conflicted pull request are wrong, and recommend merging the target branch into the source branch. This is backwards, and would result in an unintentional merge if followed. I have to tell our devs to ignore these instructions.

A case study:

I create a pull request from release/1.0 -> feature/develop/1.1 to pick up bugfixes that have been committed to the release branch only. When conflicts arise, I am still seeing instructions like this:

This pull request has conflicts. You must resolve the conflicts before you can merge:
Step 1: Fetch the changes (saving the target branch as FETCH_HEAD).

git fetch origin feature/develop/1.1

Step 2: Checkout the source branch and merge in the changes from the target branch. Resolve conflicts.

git checkout release/1.0 
git merge FETCH_HEAD

Step 3: After the merge conflicts are resolved, stage the changes accordingly, commit the changes and push.

git commit
git push origin HEAD

Step 4: Merge the updated pull request.

These instructions suggest a merge from feature/develop/1.1 -> release/1.0 which is definitely not the behavior I want. I am trying to bring back bugfixes, not bring my 1.1 code into the 1.0 release branch.

Also see STASH-3083