3 ms·

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 re

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.

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.