Merge conflicts are not detected and merges are lost under certain conditions
Merge conflicts are not detected and merges are lost when pressing the Accept Merge Request button in the merge request view under certain conditions.
GitLab version and setup
- GitLab Omnibus 8.10.2, has been kept frequently updated since at least a year ago
- I think this problem started with earlier releases already
- Repository is integrated with two-way SVN mirror with SubGit v 3.2.1
- We use GitLab CI for build, test and deploy automation
Steps to reproduce
- Create first branch
task-1, make changes, push:
git checkout -b task-1 echo 'Task-1 completed' > README.md git commit -am 'Fixed task 1' git push --set-upstream origin task-1
- Create a merge request for
task-1in GitLab, select Remove source branch when merge request is accepted. Verify that there are no conflicts, merge button should be green.
- Make conflicting changes to the same file in
git checkout master echo 'Conflicting change in master' > README.md git commit -am 'Conflicting change in master' git push
task-1merge request in GitLab again and refresh. The merge button is still green although GitLab should detect that there is a merge conflict now and the merging should be disabled.
- Press the merge button. GitLab happily does the merge, tells that The changes were merged into master. The source branch has been removed. and sets the merge request status to merged.
- Fetch changes from remote in your local Git repository and check history. The commits are not in master even though GitLab announced success (quite obvious - there was a genuine conflict). However, the upstream branch has been deleted.
‼If you don't have a local copy of the
task-1branch, the commits are lost.
- GitLab should show that the merge is in conflict state and not allow merging.
- GitLab should not report merge success and set the merge request status to merged.
- GitLab should not delete the source branch when the commits didn't really end up in master at all.
I tried to reproduce this in GitLab.com, but wasn't able to - the conflict was properly detected. So this seems to be related to the unique conditions in our setup, e.g. SubGit. Background job processing seems to lag sometimes and there are some failed jobs in Sidekiq dashboard:
Not to show SubGit in bad light - it generally seems to work well.