Cute! I was wondering why Gitlab uses MR and whether Gitlab has a better term just the other day, because I figured it was such an illogical phrase. As it happens, I am in the middle of installing Gitlab again on a newly reconfigured server and this popped up!
Then I thought "Hey, why not use the docker image?" (reeling from deep pain from the last time I tried to upgrade an LXC-based Gitlab instance across major versions), then I wondered if I needed aufs, then I wound up reading presentations about storage drivers (zfs FTW, but shame on docker for wanting an entire zpool to itself!), then decided overlay was better (and in-kernel), then I wanted to switch to a PaX kernel, now I've got a day of recompilation and installations ahead of me. But I will be glad to know MRs lie at the end ;) +1 docker bug: https://github.com/docker/docker/issues/20303
The terms GitLab uses in the first chart make a lot more sense from user experience point of view. They match how a person might describe what they're doing in English before having seen any of these tools. Good work to whoever on their team was responsible for that.
The "Gist" comparison isn't really apples-to-apples. GitHub Gists are actually git repositories themselves, and can be cloned/pulled/merged/pushed/etc. Gitlab Snippets are assets connected to the project. I remember a feature request a while back to make Gitlab Snippets more like GitHub Gists, but can't seem to find it on the actual Gitlab project's issues section now.
Huge fan of Gitlab, though. We're about to migrate from BitBucket Server née Stash to Gitlab CE.
Merge is so much clearer (as a non-coder). I've always wondered why its called Pull Request - When as a contributor, you are pushing your code into someone else's codebase and merging it going forward.
From a process standpoint, merge-request is probably more accurate, but I've always thought pull-request captured the hearts and minds of developers because it better represents how the requester feels about the request.
"Pull request" communicates "I just did a bunch of work, please recognize it and me." "Merge request" communicates "I just did something that is going to make your life hard, please do a bunch of work on my behalf." The later may be more accurate but the former is more emotionally satisfying to the dev making the request.
Edit: reducing verbosity
I might be in the minority here but i hate the term "merge request" because it implies an actual merge. Most pull requests I get against my repos are bugfixes which I typically cherry-pick or rebase against a bugfix branch but very rarely do I actually merge anything.
Merge request sounds better to me than pull request. I always found the later an awkward term to describe the merge into the master branch.
For what it's worth, GitHub came up with the awkwardly-sounding "Pull Request" nomenclature because the initial cut of Pull Requests was based on `git-request-pull(1)` (https://git-scm.com/docs/git-request-pull). After a few years, the pull request evolved into what you see today.
We always kind of hated the term "pull request". It's pretty confusing for a beginner, and for a number of years led to the idea that GitHub didn't have code review at all in the product. (For that reason, I always thought we should just call them "Code Reviews", or just "Reviews".) There were a number of attempts to change it, but they all died.
It wasn't until last year when I got a beer with an ex-Atlassian employee when we chatted about this and realized we both had hated the term and had a number of attempts to change the nomenclature, but they fizzled out. Funny how things work out.