Failed to rebase MR from forked repo

Summary

The target branch at a server-side rebase is on source repo instead of target repo. So if the branch at source repo is old, rebase then fast-forward always fails.

Steps to reproduce

At GitLab 10.1.0 or 10.1.1.

1. Make repo aaa/foo.
2. Set merge method with "Merge commit with semi-linear history".
3. Fork the repo at bbb/foo.
4. Push any commits to aaa/foo@master.
5. Create and checkout a branch bbb/foo@xxx from @master.
6. Push any commits to bbb/foo@xxx.
7. Make an MR from bbb/foo@xxx to aaa/foo@master.
8. Click the "Rebase" button in the MR page.
9. You can see "Something went wrong. Please try again.".

Example Project

I need 2 users to reproduce it. So I couldn't make an example on GitLab.com.

What is the current bug behavior?

Server-side rebase fails on a different branch on a forked repo.

What is the expected correct behavior?

Server-side rebase should be worked well.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:         Ubuntu 14.04
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.3.5p376
Gem Version:    2.6.13
Bundler Version:1.13.7
Rake Version:   12.1.0
Redis Version:  3.2.5
Git Version:    2.13.6
Sidekiq Version:5.0.4
Go Version:     unknown
GitLab information
Version:        10.1.1-ee
Revision:       5da7e03
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
DB Version:     9.6.1
URL:            http://...
HTTP Clone URL: http://.../some-group/some-project.git
SSH Clone URL:  git@...:some-group/some-project.git
Elasticsearch:  no
Geo:            no
Using LDAP:     no
Using Omniauth: no
GitLab Shell
Version:        5.9.3
Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Too long to paste. But everything is okay in my environment.

Possible fixes

I've dived into this issue and I found the reason. At the failing case, the target branch was not on the target repo. It was the same ranch on the source repo. In the above reproducing steps, the target branch is bbb/foo@master not aaa/foo@master.

This bug appears since https://gitlab.com/gitlab-org/gitlab-ee/commit/74d435c6b7e771c5e03b8f3cd603ffd262055363 by @vsizov which makes rebase use worktrees. I guess if we can make the target branch aim the target repo, this issue would be fixed.