我们正在使用GitLab 11.5.0，并注意到子模块提交有一些奇怪的行为。
我们的项目有一个子模块（我们称其为subby），并在GitLab中进行了如下设置：
group
|--project
|--subby
.gitmodules中的project文件如下所示：
[submodule "subby"]
path = subby
url = "../../group/subby.git"
.gitlab-ci.yml中的project文件包含以下内容（除其他外）：
variables:
GIT_SUBMODULE_STRATEGY: recursive
GIT_STRATEGY: clone
开发人员对subby中的代码进行了更改，更新了项目中的子模块引用，并为每个提交了合并请求。该项目的合并请求已被接受，但subby的合并请求仍在等待处理。
当运行GitLab CI时，我希望它会失败，因为subby尚未合并。但是，它以某种方式设法在subby中找到了新的未合并的提交并完成了构建。 CI日志显示它使用未合并的子模块commit创建了一个分支：
Updating/initializing submodules recursively...
Submodule 'subby' (https://gitlab-ci-token:xxxxxxxxxxxxxxxxxxxx@gitlab.example.com/group/subby.git) registered for path 'subby'
Cloning into '/builds/group/project/subby'...
From https://gitlab.example.com/group/subby
* branch c3499c2729730a7f807efb8676a92dcb6f8a3f8f -> FETCH_HEAD
Submodule path 'subby': checked out 'c3499c2729730a7f807efb8676a92dcb6f8a3f8f'
即使是陌生人，如果我通过git submodule update --init --recursive提取新合并的项目文件并更新子模块，它也可以在subby中找到未合并的提交。
在旧版本的GitLab中，这只会导致一个错误，即找不到子模块提交。我喜欢旧的行为，因为它显示了您尚未合并从属提交的事实。
我的问题：