Hacker News Reader

Comment by holman | Hacker News Reader

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.

View on HN

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.

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.

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.

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

>just like how in the southern U.S., every soda is called "Coke" even if it's a Pepsi.

Blasphemy. Atlanta can have their "Coke". Us North Carolinians drink Pepsi (born 1893 in New Bern, NC).

And to your point:

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

Never underestimate the ability of enterprises to over pay for a product despite the existence of cheaper, and arguably better solutions.

:) I made a feature request to add a new translation https://gitlab.com/gitlab-org/gitlab-ce/issues/13429

At this point I think "pull request" is part of the developer's terminology but "merge request" is just as likely to be clearly understood.

BTW, sytse, what's the best address to contact you about gitlab? There's something I'd like your thoughts on.

From what I've seen on Hacker News and Reddit over the past few months... if you just say "gitlab" 3 times in the mirror after midnight, he will appear.

Lol, that is true.

Please email me at sytse@ company domain.

Yeah, first thing I have to explain to git newbies is that a pull request is really effectively a merge-request.

I'm pulling the changes you've made into my (upstream?) repository. It's not the best name, but it makes sense. Maybe I've been using Git for too long.

I found fetch/rebase/merge to be more difficult to wrap my head around (and I still can't do an interactive rebase/squash)

Well, we're using TFS git, where you aren't forking repos on the origins, but for familiarity's sake MS calls the code-review process of merging a feature branch into dev a "pull request".

OT: VSO or self hosted? How's that working out for you? I can't use VSO at $EMPLOYER due to BlueCoat doing something very odd to the credentials in the HTTPS request - haven't able to track that down. Note that it also breaks BitBucket - 401/403 no matter what the password is.

Self-hosted. The web UI for code reviews and approvals seems pretty nice, although we're really just getting started. A lot of my stuff is still on tfsvc.

... well yeah it's confusing, but that's what happens when you cajole people into using a pull-based model so that the company can capitalize on those highly desirable market conversion/retaining effects that you wouldn't have gotten if you had done the natural thing and supported the traditional unit of change, i.e., patches.

End result: people are confused and using a procedure that's more complex than what most of their contributions call for, but that goes away when you remember what the numbers for the company are.

Reply on news.ycombinator.com