Bit off topic...
But just to illustrate: GitLab is not Git. And Git is not Gitlab.
Git has no concept of a fork being something special, i.e. in the way that gitlab has some internal link between them.
For GIT a repo is a fork, if it has the same SHA. That is all. Unfortunately not for GitLab and GitHub. They add nice features. But they also restrict those feature to their own ideas...
Here is how well the actual GIT concept works (outside of GitLab).
In the old days, when SVN was still the official repo, there had been git-mirrors. Made by people who locally run git-svn or subgit, and who regularly pushed the converted data to GitHub/Lab.
There where 2 of them (that I know of). One be Graeme, one by me.
Those 2 were individually converted. They both had the same data, but the conversion run at a different time (a few minutes, an hour...), and by a different user => So commits ended up with different SHA1 (also commit messages differed by what was added to them, like "svn-id...").
Yet, if you cloned (via add remote) both those repo into the same local repo, then the local size on disk was that of just ONE of those two. (Well a very few bytes more).
So you had 2 gits, of each considerable size. Yet, you only needed the space for one of them.
Why?
Because the commits may have add different SHA1...
But the files, and folders inside were identical. And each file, each folder has it's own SHA1. So when git downloads the 2nd repo, it does immediately see, that it already has this file/folder. And it adds no storage. So this saving happens without git even needing to compress anything.
If you did a local fork, and pushed it, then even the commits (up to were your own commits start) have the same SHA1.
So if I pull from your repo, into my local git => git knows. simple as that.
Only GitLab does not know.... And so the gitlab merge-request does not work.
But a pull request works. Because a pull request is just a message (email, post, ....) that says: please pull the branch <name> from the repo <url>. And git can do that.