11

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.

Nick
  • 4,901
  • 40
  • 61
  • So your're merging `qa` into `master` via GitLab's Merge Request feature and just tick the `Squash commits` box? It indeed does seem unreasonable to encounter conflicts in that case if there have been no changes on master. You did not merge (and squashed) an earlier version of `qa` into master? You could try to use GitLab's `Merge commit with semi-linear history` option; as long as no fast-forward merge is possible (which sould be possible), it gives you the option to rebase (which might be a good option). – kowsky Sep 07 '18 at 04:28
  • Gitlab may use git libraries which behave different with Git. As I know, JGit once had a bug which causes wrong successful merge which should have had a conflict. – ElpieKay Sep 07 '18 at 05:43
  • Is your commit tree as pretty as you described or there's something in particular in it? e.g.: reverts, merges from other branches etc. Also, if you try to merge master into your QA branch, does it also show conflicts? – everton Sep 08 '18 at 02:13
  • @everton, I have investigated a bit more now that release day is over. I updated the question and submitted an answer that raises more questions... – Nick Sep 08 '18 at 14:24

1 Answers1

9

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.

Nick
  • 4,901
  • 40
  • 61
  • Similar issues here. GitLabs squash commits in merge requests frequently leads to "unresolved conflicts" which are not actually there. The versions in the branches are almost similar but the merge result is reflecting an old state of the repository. It's really strange and seems quite uncontrolled to me. – PeMa Apr 27 '20 at 09:39
  • I have a similar issue, my `master` has 0 commits my `qa` branch is only ahead by 18 commits... but I can't merge using gitlabUI – Sporego Sep 24 '21 at 23:09