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.
- Make repo
aaa/foo
. - Set merge method with "Merge commit with semi-linear history".
- Fork the repo at
bbb/foo
. - Push any commits to
aaa/foo@master
. - Create and checkout a branch
bbb/foo@xxx
from@master
. - Push any commits to
bbb/foo@xxx
. - Make an MR from
bbb/foo@xxx
toaaa/foo@master
. - Click the "Rebase" button in the MR page.
- 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.