
Comparing Confusing Terms in GitHub, Bitbucket, and GitLab - jratkevic
https://about.gitlab.com/2016/01/27/comparing-terms-gitlab-github-bitbucket/
======
holman
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](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.

~~~
sytse
Cool to hear what your thoughts on it are. I only learned about git-request-
pull until after we named it merge requests, only then did I understand why it
was named like that.

~~~
curun1r
FWIW, despite the awkwardness of the _pull request_ terminology, Gitlab's
_merge request_ terminology was one of the major reasons why we ended up
choosing GHE over Gitlab. Pull Request, among developers, has become like
Kleenex, Xerox or any of the host of brand names that are linked with the
generic concept they implement. In most conversations, developers here have
stopped even saying the words...it's just PR without any thought to why it's
named that. Trying to force a switch to MR would have been a difficult
transition. In the end, it was easier to just pony up for GHE.

It may seem superficial, but if there's some way that you could give users the
option to surface the _pull request_ terminology rather than _merge request_ ,
even if it's just a configuration option, you may find people more receptive
to your product.

~~~
StevePerkins
I tend to agree with you that "pull request" is the term everyone uses, and
that the ship has sailed. Even when using GitLab, most people I know still use
that term anyway... just like how in the southern U.S., every soda is called
"Coke" even if it's a Pepsi.

That being said, you can't POSSIBLY be serious that this one piece of
nomenclature drove the decision between GitLab Enterprise and GitHub
Enterprise. The latter costs roughly ___5 times more_ __than the former!
Either this is unbridled hyperbole... or else money is no object at your
company, and it 's weird that you were evaluating GitLab in the first place.

~~~
curun1r
> The latter costs roughly _5 times_ more than the former!

And developers cost several orders of magnitude more than the software
license.

The decision wasn't a matter of looking at features and making a logical
decision. The decision was made by taking a sampling of developers and
allowing them to test both systems and relying on their preference. They were
unanimous that they preferred GHE. In drilling into their preference, the
merge request nomenclature was the only issue that everyone mentioned they
disliked.

And yes, the company wastes money like no other...it's part of the culture
here and the result of having cash cow products that have very little
competition. The only reason there was an evaluation was because one group
inside the company was using Gitlab and another GH.com and the company decided
to standardize on a single in-house solution.

------
contingencies
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](https://github.com/docker/docker/issues/20303)

~~~
sandGorgon
Quick answer - given by a docker developer here.

Use native devicemapper (using an lvm mounted volume). Best, fastest and least
buggy.

Overlay was flagged as massively buggy.

~~~
contingencies
_Overlay was flagged as massively buggy._

Source?

I was not planning to use LVM because it's documented[0] as slow and resource
hungry... full copy each time, massive memory use, etc.

 _CONFIG_OVERLAY_FS_ is mainline kernel code (unlike _aufs_ ) and not marked
as experimental so if docker's implementation is buggy it is more likely to be
docker's fault. It is documented by docker as being generally fast.[1]

Regardless, I don't see performance as a great concern for my workloads... I'm
more interested in the workflow enhancements.

[0]
[https://docs.docker.com/engine/userguide/storagedriver/devic...](https://docs.docker.com/engine/userguide/storagedriver/device-
mapper-driver/#other-device-mapper-performance-considerations) [1]
[https://docs.docker.com/engine/userguide/storagedriver/overl...](https://docs.docker.com/engine/userguide/storagedriver/overlayfs-
driver/#overlayfs-and-docker-performance)

~~~
sandGorgon
[https://news.ycombinator.com/item?id=11040097](https://news.ycombinator.com/item?id=11040097)

I shifted from overlay to devicemapper after this conversation. YMMV.

------
nickpsecurity
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.

~~~
sytse
Thanks! Even though few of the early developers were native English speakers
we do care a lot about naming. For me it became something very important after
learning about Domain driven design [https://en.wikipedia.org/wiki/Domain-
driven_design](https://en.wikipedia.org/wiki/Domain-driven_design)

~~~
nickpsecurity
Even more interesting that it was a second language. Also, I didn't know about
DDD. Thanks for the reference!

------
spdustin
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.

~~~
sytse
I would love to see git backed snippets as well, I made a feature proposal for
it [https://gitlab.com/gitlab-org/gitlab-
ce/issues/13426](https://gitlab.com/gitlab-org/gitlab-ce/issues/13426)

~~~
voltagex_
I used Gists quite a lot for a while, then things like the TIL post
([https://news.ycombinator.com/item?id=11068902](https://news.ycombinator.com/item?id=11068902))
and
[http://samba.org/ftp/tridge/talks/junkcode.pdf](http://samba.org/ftp/tridge/talks/junkcode.pdf)
made me realise that a lot of things are better off in full Git repos.

Maybe that says more about the Gist UI than anything else. I still think
there's a chance for a Git-backed OneNote clone to really take off - if you
hid Git away for normal users it would be really powerful.

I think some concept of scratch/temporary repositories might be better than a
Gist-style thing, but Gist with a better UI might work too.

------
redindian75
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.

~~~
nightpool
Actually, that's not what's happening. What's happening is that the project
maintainer is pulling in your changes, from your repository. It's a
decentralized vs centralized thing.

~~~
zyxley
I think you're missing the forest for the trees for here. It may _technically_
be a pull, but the thought process involved is most typically "I want to send
my code over to _____".

~~~
allendoerfer
Unfortunately git is to powerful to handle its UX like that. Users have to
understand the model behind it. If you have ever tried to work with teammates,
who did not fully get yet how git works, you know what world of pain that is.
They have to think like git works, you cannot abstract this away into their
understanding of SCM.

------
yodon
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

------
the_mitsuhiko
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.

~~~
paulddraper
Every tool I know of merges pull requests.

~~~
the_mitsuhiko
Like git pull --rebase and rebase --onto?

~~~
paulddraper
I don't know of any code review tool that uses those.

But I'd love to know. I asked
[http://programmers.stackexchange.com/q/256789/108980](http://programmers.stackexchange.com/q/256789/108980)
a while ago.

------
shmerl
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.

