Why does GitLab say there are conflicts when there have not been commits to the target branch since the last merge?

Question

We use GitLab.com for our project. We are merging code into our release branch (master) from our QA branch (qa). There have been no commits to the master branch since the last release about a month ago.

For a couple of the projects, the automatic merge fails in GitLab's UI, and I have to do it manually via the command line resolve the conflicts via GitLab's UI. I do not understand how this can occur since there are no changes on master to conflict with.

qa      --●--●--●--●--●--
           \           \
master  ----●-----------●--

When I merge the conflicts I end up just taking all changes from the qa branch anyway (git merge -X theirs). It's also not all files (thankfully!), just 5-10 changes of 5 files out of say, 300 changes in 50 files.

But I just don't understand what's triggering these conflicts.

NOTE: I do squash all commits from qa when merging into master. Now I'm thinking that could be part of the problem. Not sure how, still.

Answer 1

I think I found the issue. In one simple dependancy project it occurred, so serves well as an example.

The merges that fail to work in the UI at all (the ones that have to be resolved locally with the CLI) were merged without the issue I am describing. I have updated the question to reflect that.

The issue is that GitLab is making an automatic merge commit from the target branch to the source branch seconds before the merge in the desired direction. I verified that the projects that had 'conflicts' all had these bad merges occur. They were also the projects that were not merged manually.

$ git log --abbrev-commit --graph qa master

*   commit 92xxx (tag: v1.3.1, tag: v1.3.0, origin/master, origin/HEAD, master)
|\  Merge: 83xxx 7fxxx
| | Author: Nick
| | Date:   Fri Sep 7 00:52:37 2018 +0000
| |
| |     Merge branch 'qa' into 'master'
| |
| |     v1.3
| |
| |     See merge request translations!17
| |
| * commit 7fxxx
|/  Author: Nick
|   Date:   Fri Sep 7 00:52:37 2018 +0000
|
|       v1.3
|
| *   commit c14xxx (HEAD -> qa, origin/qa)
| |\  Merge: 76xxx 83xxx
| |/  Author: Nick
|/|   Date:   Fri Sep 7 00:52:29 2018 +0000
| |
| |       Merge branch 'master' into 'qa'
| |
| |       # Conflicts:
| |       #   langs/en-US.json
| |
* |   commit 83xxx (tag: v1.2.1, tag: v1.2.0)
|\ \  Merge: 08xxx 73xxx
| | | Author: Nick
| | | Date:   Fri Aug 3 14:09:04 2018 +0000
| | |
| | |     Merge branch 'qa' into 'master'
| | |
| | |     Merge for v1.1.2
| | |
| | |     See merge request translations!13
| | |
m   qa

master is the left line. 83xxx the merge from last release. master has no commits since the last release, except this inexplicable bad merge.

So this explains the conflicts. These conflicts appear immediately after opening a merge request in GitLab's UI, so I'm guessing the creation of the merge request is what's causing the bad merge commit. Perhaps using the 'squash commits' checkbox comes into play (it is available to select on creation of merge request, and also with the merge action of an already open merge request).

Still at a loss as to why GitLab is doing this, perhaps a bug. Next time I create merge requests that have these weird conflicts I'll leave them open to see if it did indeed create bad merge request as part of the creation process.

Update Dec 2018

Release time again. I paid attention. Still not 100% sure what's going on. Starting a merge request for the translations project, which has zero commits to master since last merge from qa.

Conflicts. Looked over them. Did not make any sense. Did not notice any commits when refreshing the repo in another tab. Clicked on 'resolve conflicts' in the UI, after completing the conflict resolution a commit from master->qa was created. It's just the Gitlab implementation's way of merging. You resolve conflicts by pulling master into QA, then merge back up. It literally says this in the UI's conflict resolution page 🙄

Or something. Drives me nuts but don't have time to dilly-dally on release day.