7 ms·

Not to pile on but also the idiots at Bitbucket cooking the "pull request" term. A "pull" is the action of merging remote changes into a local repo. What the us

Not to pile on but also the idiots at Bitbucket cooking the "pull request" term. A "pull" is the action of merging remote changes into a local repo. What the user is actually requesting is for the server to merge her/his remote changes into a branch. Gitlab calls it a "merge request" which is right. I saw someone doing a fetch and their commits disappeared! They where hidden because the repo went backwards in time. Git hides all those tidbits of information in the status but if you don't use git-prompt or powerline-shell ...you are working in the dark.

civopsec 3y ago
Github popularized “pull request” and I think it’s a fine term. Whether you are “actually” pulling from a different repository instead of just doing a “merge request” (idiosyncratic GitLab term) within the same repository doesn’t feel like an interesting distinction.
- fragmede 3y ago
  If you're treating git as a centralized VCS, that is, there is only a singular upstream, perhaps, say, GitHub.com, then that makes sense. That, however, is not the only way to use the tool (though GitHub.com obviously has their own opinions on whether that should be the case or not), but the upstream repository that you're pulling from certainly it's an important distinction if you're using the tool beyond how GitHub.com wants you to.
  - civopsec 3y ago
    So you should change your terminology depending on some “how X” your workflow is? If you are working with two repositories between yourself and a teammate then it becomes “pull request”, but then if you move back to the centralized company upstream then you’re doing “merge requests”? The distinction is not interesting enough to, well, make a distinction over. > That, however, is not the only way to use the tool And “pull request” somehow is exclusionary? No, because you can use it to talk about both inter- and intra-repository changes.
    - lemoncucumber 3y ago
      Yeah, `git pull` is just shorthand for `git fetch` followed by `git merge`, so it's technically a superset of a "merge request". And it also handles the cross-repo case, which is a common case in the Github model of "make your own personal fork of the upstream repo and send PRs from there," which has advantages -- it allows random people to send PRs without needing to give them permission to e.g. pollute the upstream repo's branch namespace.
- bjornasm 3y ago
  Disagree. Why are you both pulling when you want code from the repo and when you want to put your code up to someone elses repo?
  - Ajedi32 3y ago
    You pull when you want code from their repo, they pull when they want code from your repo. You don't have permission to push to their repo, so instead you request that they pull from yours.
    - yCombLinks 3y ago
      They already have my branch though! I had to push it to them before I could request they pull it!
      - Ajedi32 3y ago
        No you pushed it to your own GitHub repository. So they need to pull from your repository into theirs. Though I agree the situation is somewhat muddied by the fact that you can create pull requests for branches in the same repository (even though that's not the normal workflow). GitLab's "merge request" terminology is more accurate for that use case.
        yCombLinks 3y ago
        Ahh, for me it's pull requests into the central work repo, not GitHub. That is different.
  - MereInterest 3y ago
    If I loan you money, my money goes to you. If I request a loan from you, your money goes to me. If I pull your code, your code goes to me. If I request that you pull my code, my code goes to you.
thomastjeffery 3y ago
From the server's perspective, you are the remote and it is local. You are requesting that the server pulls from you. ...at least, that's how I always read it.
- dboreham 3y ago
  I thought it originated in a decentralized git use case where developer A asks developer B to pull their proposed new code into their (local) repo. So predating server hosted git. Perhaps I made that up though.
  - thomastjeffery 3y ago
    That's generally my point: despite the server presenting itself as a centralized "hub", it is really just another decentralized user of a decentralized git repo. From a git perspective, there is no meaningful difference between server and client.
    - PaulDavisThe1st 3y ago
      i prefer to talk about a project's "canonical repository". so for example, the main project i work on has two primary developers, each of us doing a bunch of mostly independent work. we could set things up so that we simply push/pull between those two repositories. but that's a much less useful way to work than to denote a repository somewhere as the "canonical" one, and then all those involved pull from it and push to it. the presence/absence of a server associated with a repo is a bit of a red herring - what matters is the workflow associated with the different repos. my own repo is just a local private one of no particular significance, as is that of my colleague. by contrast, git.ardour.org is canonical (and, as an aside, github.com/Ardour/ardour is merely a mirror).
      - MereInterest 3y ago
        Except that there is no such canonical repository. I can set your laptop as a remote and pull from you. You can set my raspberry pi as a remote and pull from me. There is no such thing as a “canonical” repository in git. Such a concept only exists in the systems built on top of git, if it exists at all.
jordigh 3y ago
The original idea, as enshrined in git-request-pull(1), was that we would all have our own git repos somewhere, kernel.org/git or redhat.com/git, and then we would request to pull from each other by sending emails to each other to pull from each other repos across different servers, even different organisations and different domains. Github took inspiration from git's request-pull command but instead reinterpreted it as merging from one github repo to another.
bjornasm 3y ago
This is the one that allwaays was impossible for me to wrap my head around. Surely it is a push or merge request not a pull request.
- PH95VuimJjqBqy 3y ago
  It's a request for the other person to pull, it's only a push if the requestor is doing the action (and they're not).
- ajross 3y ago
  So... technically no. It really is a "pull" request from Github's perspective. A PR is (1) a bunch of review/comment/history/hook tracking in the web/cloud backends and (2) a single git branch name somewhere else on github, writable by the author, which contains the changes. The underlying action of merging a "pull request" is to pull from the submitted branch to the target branch. It's no different than Linus doing it from a maintainer branch.
ptx 3y ago
The Git book [0] explains where this term comes from and how it makes sense. In short, it's not a request to a server but to another person. You're requesting that they pull your branch to take a look at the changes you want to contribute to the project. [0] https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_public_project https://git-scm.com/book/en/v2/Distributed-Git-Contributing-...
- yCombLinks 3y ago
  It doesn't make sense in the context nearly everyone uses git in. How many people mean that when they say pull request? Roughly 0%

civopsec 3y ago

Github popularized “pull request” and I think it’s a fine term. Whether you are “actually” pulling from a different repository instead of just doing a “merge request” (idiosyncratic GitLab term) within the same repository doesn’t feel like an interesting distinction.

fragmede 3y ago
If you're treating git as a centralized VCS, that is, there is only a singular upstream, perhaps, say, GitHub.com, then that makes sense. That, however, is not the only way to use the tool (though GitHub.com obviously has their own opinions on whether that should be the case or not), but the upstream repository that you're pulling from certainly it's an important distinction if you're using the tool beyond how GitHub.com wants you to.
- civopsec 3y ago
  So you should change your terminology depending on some “how X” your workflow is? If you are working with two repositories between yourself and a teammate then it becomes “pull request”, but then if you move back to the centralized company upstream then you’re doing “merge requests”? The distinction is not interesting enough to, well, make a distinction over. > That, however, is not the only way to use the tool And “pull request” somehow is exclusionary? No, because you can use it to talk about both inter- and intra-repository changes.
  - lemoncucumber 3y ago
    Yeah, `git pull` is just shorthand for `git fetch` followed by `git merge`, so it's technically a superset of a "merge request". And it also handles the cross-repo case, which is a common case in the Github model of "make your own personal fork of the upstream repo and send PRs from there," which has advantages -- it allows random people to send PRs without needing to give them permission to e.g. pollute the upstream repo's branch namespace.
bjornasm 3y ago
Disagree. Why are you both pulling when you want code from the repo and when you want to put your code up to someone elses repo?
- Ajedi32 3y ago
  You pull when you want code from their repo, they pull when they want code from your repo. You don't have permission to push to their repo, so instead you request that they pull from yours.
  - yCombLinks 3y ago
    They already have my branch though! I had to push it to them before I could request they pull it!
    - Ajedi32 3y ago
      No you pushed it to your own GitHub repository. So they need to pull from your repository into theirs. Though I agree the situation is somewhat muddied by the fact that you can create pull requests for branches in the same repository (even though that's not the normal workflow). GitLab's "merge request" terminology is more accurate for that use case.
      - yCombLinks 3y ago
        Ahh, for me it's pull requests into the central work repo, not GitHub. That is different.
- MereInterest 3y ago
  If I loan you money, my money goes to you. If I request a loan from you, your money goes to me. If I pull your code, your code goes to me. If I request that you pull my code, my code goes to you.

thomastjeffery 3y ago

From the server's perspective, you are the remote and it is local. You are requesting that the server pulls from you. ...at least, that's how I always read it.

dboreham 3y ago
I thought it originated in a decentralized git use case where developer A asks developer B to pull their proposed new code into their (local) repo. So predating server hosted git. Perhaps I made that up though.
- thomastjeffery 3y ago
  That's generally my point: despite the server presenting itself as a centralized "hub", it is really just another decentralized user of a decentralized git repo. From a git perspective, there is no meaningful difference between server and client.
  - PaulDavisThe1st 3y ago
    i prefer to talk about a project's "canonical repository". so for example, the main project i work on has two primary developers, each of us doing a bunch of mostly independent work. we could set things up so that we simply push/pull between those two repositories. but that's a much less useful way to work than to denote a repository somewhere as the "canonical" one, and then all those involved pull from it and push to it. the presence/absence of a server associated with a repo is a bit of a red herring - what matters is the workflow associated with the different repos. my own repo is just a local private one of no particular significance, as is that of my colleague. by contrast, git.ardour.org is canonical (and, as an aside, github.com/Ardour/ardour is merely a mirror).
    - MereInterest 3y ago
      Except that there is no such canonical repository. I can set your laptop as a remote and pull from you. You can set my raspberry pi as a remote and pull from me. There is no such thing as a “canonical” repository in git. Such a concept only exists in the systems built on top of git, if it exists at all.

jordigh 3y ago

The original idea, as enshrined in git-request-pull(1), was that we would all have our own git repos somewhere, kernel.org/git or redhat.com/git, and then we would request to pull from each other by sending emails to each other to pull from each other repos across different servers, even different organisations and different domains. Github took inspiration from git's request-pull command but instead reinterpreted it as merging from one github repo to another.

bjornasm 3y ago

This is the one that allwaays was impossible for me to wrap my head around. Surely it is a push or merge request not a pull request.

PH95VuimJjqBqy 3y ago
It's a request for the other person to pull, it's only a push if the requestor is doing the action (and they're not).
ajross 3y ago
So... technically no. It really is a "pull" request from Github's perspective. A PR is (1) a bunch of review/comment/history/hook tracking in the web/cloud backends and (2) a single git branch name somewhere else on github, writable by the author, which contains the changes. The underlying action of merging a "pull request" is to pull from the submitted branch to the target branch. It's no different than Linus doing it from a maintainer branch.

ptx 3y ago

The Git book [0] explains where this term comes from and how it makes sense. In short, it's not a request to a server but to another person. You're requesting that they pull your branch to take a look at the changes you want to contribute to the project. [0] https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_public_project https://git-scm.com/book/en/v2/Distributed-Git-Contributing-...

yCombLinks 3y ago
It doesn't make sense in the context nearly everyone uses git in. How many people mean that when they say pull request? Roughly 0%