8 ms·

Comparing Confusing Terms in GitHub, Bitbucket, and GitLab

104 points by jratkevic 11y ago

nickpsecurity 11y ago
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 11y ago
  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 11y ago
    Even more interesting that it was a second language. Also, I didn't know about DDD. Thanks for the reference!
contingencies 11y ago
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 11y ago
  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 11y ago
    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/device-mapper-driver/#other-device-mapper-performance-considerations https://docs.docker.com/engine/userguide/storagedriver/devic... [1] https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/#overlayfs-and-docker-performance https://docs.docker.com/engine/userguide/storagedriver/overl...
    - sandGorgon 11y ago
      https://news.ycombinator.com/item?id=11040097 https://news.ycombinator.com/item?id=11040097 I shifted from overlay to devicemapper after this conversation. YMMV.
redindian75 11y ago
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 11y ago
  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.
  - mikegioia 11y ago
    I think the word ordering is confusing, though. It's a Push Request and a Request to Pull.
    - spdustin 11y ago
      I think it's arguable either way, honestly. When you order a pizza, would you say it is a Pizza Request, a Toppings Request, a Transaction Request or a Request for Pizza with My Toppings Merged into the Default Configuration? Pull Request makes sense to me, Merge Request makes sense to me too. To others, one may resonate more. Rosetta Stone posts like this can be helpful to people who are used to a particular vernacular, and I don't think the semantic distinction is itself the point. Other than the Gist comparison (which I mentioned in another comment), I think this post was helpful. It's truly inspiring how _present_ Gitlab are in the communities they serve.
    - rejschaap 11y ago
      Yeah, you are right. "Pull request" in itself could be parsed as a command, but it is a thing really. Used in a command you would say "Send pull request". Where send is the verb and "pull request" is the object. In my native language it would actually be a single word. I have seen some people write it as pull-request, which removes the ambiguity. Note that "Merge request" doesn't solve this problem. From a user-interface design perspective I would say it would be bad to have a button or link that solely says "pull request" or "merge request". It should probably be preceded by a verb such as view, send or process. Also, pulling a pull request or merging a merge request is just weird and doesn't make sense.
spdustin 11y ago
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 11y ago
  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_ 11y ago
    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.
holman 11y ago
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.
- carussell 11y ago
  ... 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.
- sytse 11y ago
  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 11y ago
    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.
the_mitsuhiko 11y ago
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 11y ago
  Every tool I know of merges pull requests.
  - the_mitsuhiko 11y ago
    Like git pull --rebase and rebase --onto?
    - paulddraper 11y ago
      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.
yodon 11y ago
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
shmerl 11y ago
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.

104 points by jratkevic 11y ago

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 11y ago
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 11y ago
  Even more interesting that it was a second language. Also, I didn't know about DDD. Thanks for the reference!

contingencies 11y ago

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 11y ago
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 11y ago
  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/device-mapper-driver/#other-device-mapper-performance-considerations https://docs.docker.com/engine/userguide/storagedriver/devic... [1] https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/#overlayfs-and-docker-performance https://docs.docker.com/engine/userguide/storagedriver/overl...
  - sandGorgon 11y ago
    https://news.ycombinator.com/item?id=11040097 https://news.ycombinator.com/item?id=11040097 I shifted from overlay to devicemapper after this conversation. YMMV.

redindian75 11y ago

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 11y ago
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.
- mikegioia 11y ago
  I think the word ordering is confusing, though. It's a Push Request and a Request to Pull.
  - spdustin 11y ago
    I think it's arguable either way, honestly. When you order a pizza, would you say it is a Pizza Request, a Toppings Request, a Transaction Request or a Request for Pizza with My Toppings Merged into the Default Configuration? Pull Request makes sense to me, Merge Request makes sense to me too. To others, one may resonate more. Rosetta Stone posts like this can be helpful to people who are used to a particular vernacular, and I don't think the semantic distinction is itself the point. Other than the Gist comparison (which I mentioned in another comment), I think this post was helpful. It's truly inspiring how _present_ Gitlab are in the communities they serve.
  - rejschaap 11y ago
    Yeah, you are right. "Pull request" in itself could be parsed as a command, but it is a thing really. Used in a command you would say "Send pull request". Where send is the verb and "pull request" is the object. In my native language it would actually be a single word. I have seen some people write it as pull-request, which removes the ambiguity. Note that "Merge request" doesn't solve this problem. From a user-interface design perspective I would say it would be bad to have a button or link that solely says "pull request" or "merge request". It should probably be preceded by a verb such as view, send or process. Also, pulling a pull request or merging a merge request is just weird and doesn't make sense.

spdustin 11y ago

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 11y ago
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_ 11y ago
  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.

holman 11y ago

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.

carussell 11y ago
... 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.
sytse 11y ago
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 11y ago
  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.

the_mitsuhiko 11y ago

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 11y ago
Every tool I know of merges pull requests.
- the_mitsuhiko 11y ago
  Like git pull --rebase and rebase --onto?
  - paulddraper 11y ago
    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.

yodon 11y ago

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

shmerl 11y ago

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.