Better merge request manual instructions

I noticed the current instructions for manually merging a merge request that was submitted from a fork could create unnecessary merge requests or strange history. Imagine this:

1. Alice creates a repository and commits / pushes a single commit with SHA1 A to master.
2. Bob forks this repository and creates a new branch myfeature on master (A)
3. Alice commits B to master (which has the parent A)
4. Bob creates two commits on myfeature P and Q.
5. Bob submits the merge request to merge his myfeature into Alice's master branch.
6. Alice follows the manual merge request instructions:
7. git checkout -b bob/repo-myfeature master
8. git pull http://... myfeature

The branch bob/repo-myfeature was created from Alice's current master, which was B. When the pull is executed, git will fetch Bob's branch and then merged the fetched branch Q into the current branch's location B. This creates an unnecessary merge commit from master into the branch Alice is trying to merge. No harm is done, but the history is a bit messier.

This is even worse if Alice has set git pull to rebase by default. In this case, the commit B is rebased on top of Q. When Alice checks out master and merges in the branch, there will actually be a duplicate B commit.

These new instructions instead tell the user to fetch Bob's myfeature branch. This will fetch the necessary commits P and Q and create a temporary ref FETCH_HEAD pointing to Q. Alice will then create her local bob/repo-myfeature branch starting at FETCH_HEAD. No unnecessary merge commits, and no accidental rebasing.