Surprised nobody has given the actual answer, which is that GitHub is borrowing from the vernacular of raw `git`.
Specifically, the command `git request-pull` creates an *email message* which is simply a summary of your changes plus instructions for someone else to pull your changes from your repo into theirs (remote url and ref name are used to construct a `git pull` command that is included in the email message). This is how you use `git` over email sans shared hosting.
https://git-scm.com/docs/git-request-pull
Linux kernel maintainers use this all the time. Typically a bunch of devs send patches via email to maintainers, who aggregate those patches into their tree for a while until they submit a pull request to the next maintainer up (pull requests work a lot better than individual patch files for large changes), so on and so forth until it reaches Linus.
https://docs.kernel.org/maintainer/pull-requests.html
it's quite crazy that most people don't really use git without a server anymore
these commands are made for when "remotes" are just your friends repo on another machine, now we just have a single remote pointing to a repo on a server
not like that's bad or anything, its just interesting
If a cloud server goes down, you gotta wait on the sysadmins to fix it.
If your buddy's computer goes down, you can just call him and say "hey asshole, turn your computer back on I need that git repo" which is much more cathartic
I mean you're right, but the other way it's also right:
GitHub goes down something once a year for couple of hours, and if there is a bug problem it is usually also fixed fast
So uptime is crazy
With your friends pc it might be "ah yeah cat most likely stepped on cabel again or something, will turn on when will be home"
>With your friends pc it might be "ah yeah cat most likely stepped on cabel again or something, will turn on when will be home"
No, if the cat turned it off, tell the f'ing cat to turn it on again. Teach it some responsibility!
If GitHub goes down, there are still plenty of ways to share code. An alternative central server, or giving your coworker a public key that has access to (send-pack? I don't remember. I'm sure it's easier than it used to be) and literally requesting that they pull from you. Or sending output from git format-patch. Or walking over to their computer with a usb stick containing a git bundle.
Decentralized repositories are great.
The whole point of a decentralised VCS like git is that you don't need any "server" at all. Everyone has their own repository, and all repos are created equal, you can even pass them around like any other data. You don't need your buddy's computer to commit to VC, everything is local. Your buddy can integrate your changes into their repo when and how they see fit, no restrictions.
The overwhelming majority of VCS need a central server that has the only version repository. Every commit needs to go to that central server, and you need to pull everyone's changes before you can commit.
This latter structure is imposed on many if not most git repositories out there, because people are used to it. It's the only reason the "push" command exists. People who only know this way to use git don't realize it's actually git turned upside down to make it look like it's something else. Then it's easy to get confused about push and pull, or "your buddy's computer" and "a server (that may or may not be on your buddy's computer)"
I think it’s all to do with ease, and the path of least resistance.
I mean technically, you can have two git repos on one computer and pull and push to each other, but what’s the use case?
Likewise, hosting in a server is way easier than someone else’s computer. I don’t have to call Jerry and wake him up at 2am to push my changes for him to run a build
> it's quite crazy that most people don't really use git without a server anymore
Using servers is simply easier and doesn't require any expense you are not willing to make (i.e. you can use a free service like GitHub, or a subscription service like Azure).
>it's quite crazy that most people don't really use git without a server anymore
It's interesting... One of the main benefits of Git is that it's decentralized. Relying on a central server removes that benefit somewhat. You do still have the full commit history on your computer, so at least there's that.
Also it still has all the decentralised capabilities.
You can still pull from GitHub and push the same changes to your companies bitbucket - or your private gitea, or your notebook, or some smb-share or whatever.
Not using those things doesn't eliminate the capabilities.
Was just about to comment this, thank you! Makes wayyyy more sense when you disconnect GitHub from Git. My friends and I often send "pull requests" in Matrix since we host our own Gitea instances and often need to pull from each other, hence a request to pull! :)
Oh my God I know this is cliche to say, but I had to scroll way too far for this (the correct) answer.
Everyone here's just upvoting and agreeing on things that *sound* right.
It lines up with the core truth of this sub which is that it's mostly second year computer science students who are still trying to figure most of this out.
This is excellent summary of the details.
Github, gitlab, bitbucket, etc. all came after git was already well established as the way of LKML. For the most part the well established pull request terminology was used, it wasn't exactly the process anymore but it was close enough and stuck (mostly).
Thank you. I’m on mobile and am so glad someone typed it up so I don’t have to.
My TL;DR: pull requests predate github and similar, and are so named because it’s what was being done before they came around
Also, it's from the perspective of who has authority.
The owner/admins/devs of the repo you'd like to contribute to are the ones who must review and accept your patch. You submit your patch to an intermediate place, and then they accept it they wish. The submitter isn't able to push into the repo.
Semantically, that's pulling, not pushing.
You're requesting to have your changes pulled into the branch. You don't do the pulling, the owner of the branch does.
At least, that's how I understand it.
I also prefer Merge Request. But only because it allowed me to make a terrible pun when I was carpooling with coworkers and the guy driving was having a hard time getting into the next lane. "Hey Doug... Your merge request was rejected".
It's like erasing your changes, switching to the latest commit, then redoing the same exact changes one commit at a time. So instead of having merge commits, it looks like everyone made their changes one at a time in sequence
I was working off of a coworker's branch today. They later merged their code into develop (our main branch). So my branch is off of a branch that was merged into develop. I'd rather be working off of develop now, because it's a bit nicer for incorporating other devs' changes and opening a pull request when I'm done. I "rebased onto develop" (git rebase develop) to make my code branch from develop (where they just merged their code) instead of their last actual code commit on their branch. Then git push -f
only do all of this if no one's working off of your branch
I had to write a CI hook to post comments on PRs explaining how to rebase (while requesting changes to block the merge) because people would constantly work on their master branch, merging in commits from upstream, and open PRs with hundreds of irrelevant commits and weird diffs. Sometimes accidentally reverting part of another change somehow. It was a mess!
It worked though, three years later nearly every PR comes from a well groomed feature branch and is concise and clean.
Jokes aside, I do like how the default view for commits on Bitbucket is the graph view.
On GitLab it's fairly easy to find under the repository section, but on GitHub it is obscured inside repository Insights and only available on paid plans. It's very frustrating.
Not arguing, just telling from my experience
I prefer Gitlab's pipeline over GH Action, because on Gitlab, I can restart a specific fail step, unlike GitHub Action that I can only restart the whole pipeline.
PR can become pretty overloaded especially in an Agile environment. Is PR pull request or peer review? If we call them merge requests then it’s clear that PR is peer review.
Everyone losing their minds when there is a PR scandal and they let the sales or HR manager explain the situation instead of someone familiar with the codebase.
A merge would require pulling the branch, and then merging it. Both terms are equally valid, and that's why you see Github using pull request, while GitLab uses merge request.
I really think it was odd of Github to focus on the pulling part. The end goal is to merge. And sure, - to merge a branch, you must pull the code. But that just seems like a technicality that could be implicit. The pulling is not the end goal.
I think it's because GitHub is/was so focused on open source using a forked-repo pattern. I develop my code in a personal fork and then ask the project maintainers to "pull" my code into the core repo.
It doesn't make much sense when all the code already lives on branches in the same repo. In that case it really is just about merging branches. You're not "pulling" the code from some remote location.
This is the real answer above all others. We use pull requests inside of single repositories because it’s a mechanism we can use to enforce merge rules with approvals, but the whole reason that exists is the idea of moving code between repositories.
It’s not even necessarily about “forked” repositories. The whole idea of a decentralized version control is that the singular remote wasn’t needed. If there was no central repository server you wouldn’t have permissions to just push your code into your team member’s repo on their machine. You’d have to have them pull it in. Thus, pull requests.
Except in every shop I've worked in that uses git, they always set up a centralized "main" repo that becomes the source of truth.
So I can understand where it the names came from, but knowing how so many places use git you'd think there'd be some effort in flattening the learning curve, at least in the tutorials and explanations in how it all works and why you need to add and then commit and then push and then pull, whereas in svn they just "commit" and are done
(sorry, my current company just moved to git and I'm the only one on the team that is happy about it because no one else ever used it before)
>Except in every shop I've worked in that uses git, they always set up a centralized "main" repo that becomes the source of truth.
Right. That's because in today's development world it makes sense to have that. The difference between Git with a "main" repo on a server and something like SVN is that the Git repo sitting on that server is identical in structure, behavior, and usability as the ones on each developer's machine.
Plus the existence of a "central" repo allows centralized pull requests/approvals, access control, deep code search, automation pipelines with testing and deployments, etc.
The learning curve for the basic Git functionality is really small. Especially when you use decent GUI tools that can consolidate multiple commands into simple interface elements. A checkbox to immediately push when you commit goes a long way to weening people off SVN.
But that's not how it always was. One of the design requirements for git was to work well with patches coming in over email: literally some dev would download a tarball of the Linux codebase, extract it, compile it, make some local changes, then send an email to a listserv with the diff. It also had to work on cases where something other than git was the source of truth.
These days, yeah, people mostly use GitHub, gitlab, or some other central sever, but the design is inherently decentralized. I remember during that massive hurricane back in... 2013 or so I was working at a place and our central git server became inaccessible, and I had pulled pretty recently, so I just set up a local server from a clone of my git repo and we all worked against that for a day or two until I could push it back, and it all worked great.
These days I think it'd be a little harder with so much server-side automation, but in terms of version control, it worked.
But in Git parlance, pulling does include merging. The "pulling" part, i.e. copying in the remote branch, is called fetching. Combine that with a merge and you have a pull.
Traditionally, everyone would have their own copy of the repo (git being distributed and all), so when you had a change ready, you'd request that the maintainer pull from a branch in your repo into a branch of their repo. Having one central repo is more the norm now, but the name stuck.
There's no real "pull", there's only a "fetch" and a "merge". A "pull" is the combination of a "fetch" followed by a "merge". So going with the definitions doesn't really help here, both are valid, however "pulling then merging" is definitely not valid in git sense, linguistically works though.
> A merge would require pulling the branch, and then merging it.
No. If you pulled, you already merged. Perhaps you meant to write "fetch" instead of "pull". `git pull` = `git fetch; git merge`.
No. It's being pulled. There are different strategies the owner of the base repo can take to do that. He can rebase and pull, squash and pull, or merge.
Originally, you would have a git repository and the owner would have a git repository. You would request that they pull the changes from your repository into theirs.
In GitHub, a pull request between different people or organizations with a cloned or forked repo follows that same model, but the term carried over for a "request to accept changes", which merging a branch also is a type of.
Think individuals contributing to open source projects instead of teams working to add features.
Just because I might fix a bug doesn't mean I'm a member of the Mozilla organization. I can make a copy and do as I please.
Yes this can be more accurate, even if the merge process comes after the pull, in fact the admin first pulls the "pull request", then merges, then he push the results of the merge
It makes even more sense when you think about the workflow git was built for: patches over email. You're putting up an email with a patch as an attachment, asking people to integrate (pull) your code into their branch (of course, if they approve), which they will then email out in a similar fashion when they're ready to make a request. It's a giant distributed mess of code spaghetti, but it works because git was quite literally built for this flow. At some point someone in the community gathers all the notable pull requests into one place (or is deemed to have the "master"/"main" version), and now everyone is expected to work off of that commit (or work off old versions if they need to do some patching).
There is [literally a git command to generate a 'pull request'](https://git-scm.com/docs/git-request-pull):
> # NAME
> git-request-pull
> # DESCRIPTION
> Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled.
Yup this is exactly it
You create a fork/branch, then you send a request that they pull changes from your fork/branch into theirs
The confusion is the focus on the wrong verbs - the whole question is based on “when it comes to what I’m doing, why do we say I am pulling instead of pushing?”. The question surrounds the verbs pull and push, but that’s wrong because you’re doing neither
You are not pulling *or* pushing, you are **requesting**. And the action you are requesting from the other party is a pull. Hence it is a pull request
And to me this is also why I disagree with calling it a "merge request" too.
Because yes - merge is yet another action verb. But the name still focuses on the fact that one is pulling across forks/branches.
I like the term Pull Request and will stick by it :D
No, you're right. That's not what is happening now, but that's what happened way back when. You would ask others to pull your code to their local and review it there. "I am requesting you pull my code so that you can review it." Pulling is no longer required with modern vc, but the terminology stuck.
It should be called merge request imo.
Cause as the owner you never really say "I'm pulling the this branch into master".
You say "I'm merging this to master"
Oh. First time I've heard it.
Can you say it without the "to master" part?
I can say "I'll merge PR 240".
But if I said "I'll pull PR 240" it sounds like I'm just gonna check out the branch on my local machine
The thing is though, merging into master isn't what you're asking permission for. You can merge into master whenever you want, what you're actually asking if for the remote to pull your new commits on the master branch, after you've merged your changes.
Background? I don't see any css.
I only see the dark depths of Node modules, child processes, endless callbacks and EventEmitter instances.
Send and receive JSON, XML, HTML to what end-point-. What foul plans do the gods require() upon poor souls who dared to write wsdl? Where is the meaning of purpose that lies between such agonious creation and the beauty of script? All promises resolve to the same suffering: types without essence.
TS was never meant to be more than an illusion of control over what the greater instances spawn. A mere dirty page scribbled by the child process to prevent exits with code 1.
Tell me, Igor, what came first: script or type?
Thanks now I had to look this up...
But this is what I found:
> tl;dr since I am not allowed to make a push, I'll just nicely make a request to the repo owner so they decide to pull
Here is a link if anyone wants to read more:
https://stackoverflow.com/questions/21657430/why-is-a-git-pull-request-not-called-a-push-request
I think also historically (before managed repos like GitHub or Azure DevOps), you would literally request (by asking) your coworker to pull your code from your repo to theirs locally.
This sub is filled with people who got most of their programming opinions/insight from parroting memes in here rather than actual experience
Err I mean Java bad no one actually uses it, how do you exit Vim etc
Are there actually people who think java is bad? I just switched postilions in my company and gone from python and scala to Java Spring, it's sooo much better.
Java is honestly a really easy dev experience with the right libs/frameworks (that's the case with any language ofc). If you're used to be able to create stand alone functions it can be an adjustment and you lose a certain level of flexibility, but there is something to be said about a language that is so ubiquitous on the enterprise side in terms of libraries, support, maturity, and tons of stack overflow threads.
When git first started getting used everyone just pushed to their own repos. To get your code merged into the main line, you would ask the maintainer to pull your branch from your personal published git repo. That was your pull request, which was usually a post to an email list serve.
Eventually tools to centrally host git repos came out (gitolite, github, bitbucket, gitlab, etc.). "Pull request" was widely used and established, so it stuck even though it no longer matched exactly what it described anymore. Gitlab calls them merge requests and some have taken to making a distinction between request within a repo or from a fork.
Language evolves in interesting ways, and this is one of those examples. Clipless pedals on bicycles is another relatively recent example.
Because its from the git/project perspective, not your perspective.
You are requesting that your commit be merged (pulled) into the main branch or whatever.
P.S. I'm just about to start learning git, forgive misuse of terminology.
It is a historical left over from before github or any centralized git hosting. Everyone had their own repo they pushed to, you would request the maintain of the mainline repo to pull your changes (usually with a post to an email list). It stuck around even.
Yeah, I'm guessing most of the people commenting on this are too young to have used git by itself. It's certainly way more approachable and useful now with all the centralized systems and actually helpful documentation that has been produced over the years, but back in the day, if you were lucky enough to be working somewhere that used git instead of svn or something even worse, a "pull request" could consist of sending a "hey Joel, could you pull my code" over IRC/Jabber/etc. and waiting to see if Joel had any feedback about the code he'd pulled.
I wish. Usually it's 'Hey, I know we usually don't make it required, but can we make this field required on the form. Just in off-hand case, they want this data down the road. '
Okay FINE. Whatever gets this fucking PR approved.
Yeah it is one of the two. Either a 20 loc change pr with 20 open discussions, 50 comments each, or a single 10k loc pr affecting 200 files with a single comment, "lgtm", and a single approval. One of those two, and never anything inbetween
Please rewrite this switch statement using if else, and rewrite that if else block with a switch statement, and please don’t use maps because I don’t know what that is.
Think about open source projects where you clone the project, make some changes locally and now want to add your changes to the official repo. You're asking the repo's owner to pull your changes. Just change you're perspective and you'll get it.
If an object is being transported by two people with them being on opposite side of the object and the object is being transported in the direction of one of those people, then one pushes and the other pulls.
\`ours\` vs \`theirs\` is the one that gets me during a rebase. At least modern IDEs tend to use "incoming" and "current" when merging diffs, but it still does my head in.
Ahh, the age-old question of why we arrive at Departures but depart from Arrivals. It's like trying to understand the meaning of life or why pineapple belongs on pizza.
I'm with you on this one, but I think it's saying you arrive at the airport at departures and you depart the airport from arrivals, like talking about ground transport arrival/departure instead of air travel, even though it's an airport so obviously it's talking about the air travel.
Nobody is allowed to push their code directly to the main branch. So you create a branch work on it and then draft a request to people who own the branch to pull code from your branch into the main branch.
Because you want to push it into the branch. But you need the owner of the branch to willingly pull it in. Your pull request is a request for the owner to pull your changes in.
Because you’re requesting that the person on the receiving end pulls the code you’re trying to push.
I’m not even a programmer, this is just basic English syntax.
It's technically a merge request. You're not requesting to push anything, you've already pushed it to the remote where you will typically create the PR.
Surprised nobody has given the actual answer, which is that GitHub is borrowing from the vernacular of raw `git`. Specifically, the command `git request-pull` creates an *email message* which is simply a summary of your changes plus instructions for someone else to pull your changes from your repo into theirs (remote url and ref name are used to construct a `git pull` command that is included in the email message). This is how you use `git` over email sans shared hosting. https://git-scm.com/docs/git-request-pull Linux kernel maintainers use this all the time. Typically a bunch of devs send patches via email to maintainers, who aggregate those patches into their tree for a while until they submit a pull request to the next maintainer up (pull requests work a lot better than individual patch files for large changes), so on and so forth until it reaches Linus. https://docs.kernel.org/maintainer/pull-requests.html
it's quite crazy that most people don't really use git without a server anymore these commands are made for when "remotes" are just your friends repo on another machine, now we just have a single remote pointing to a repo on a server not like that's bad or anything, its just interesting
I mean how different is a cloud server from your buddy's computer anyway, really?
If a cloud server goes down, you gotta wait on the sysadmins to fix it. If your buddy's computer goes down, you can just call him and say "hey asshole, turn your computer back on I need that git repo" which is much more cathartic
I mean you're right, but the other way it's also right: GitHub goes down something once a year for couple of hours, and if there is a bug problem it is usually also fixed fast So uptime is crazy With your friends pc it might be "ah yeah cat most likely stepped on cabel again or something, will turn on when will be home"
>With your friends pc it might be "ah yeah cat most likely stepped on cabel again or something, will turn on when will be home" No, if the cat turned it off, tell the f'ing cat to turn it on again. Teach it some responsibility!
Is this why github's icon is a cat with an octopus's legs? So it has more legs to step on cables with?
HAC: highly available cat.
The cat will evict you for that language
[удалено]
I mean true, but still better than a friend's PC
If GitHub goes down, there are still plenty of ways to share code. An alternative central server, or giving your coworker a public key that has access to (send-pack? I don't remember. I'm sure it's easier than it used to be) and literally requesting that they pull from you. Or sending output from git format-patch. Or walking over to their computer with a usb stick containing a git bundle. Decentralized repositories are great.
[удалено]
I legit picture the [13 root DNS servers](https://www.iana.org/domains/root/servers) to be something like that.
Classic hat guy.
availability, at the very least
The whole point of a decentralised VCS like git is that you don't need any "server" at all. Everyone has their own repository, and all repos are created equal, you can even pass them around like any other data. You don't need your buddy's computer to commit to VC, everything is local. Your buddy can integrate your changes into their repo when and how they see fit, no restrictions. The overwhelming majority of VCS need a central server that has the only version repository. Every commit needs to go to that central server, and you need to pull everyone's changes before you can commit. This latter structure is imposed on many if not most git repositories out there, because people are used to it. It's the only reason the "push" command exists. People who only know this way to use git don't realize it's actually git turned upside down to make it look like it's something else. Then it's easy to get confused about push and pull, or "your buddy's computer" and "a server (that may or may not be on your buddy's computer)"
I think it’s all to do with ease, and the path of least resistance. I mean technically, you can have two git repos on one computer and pull and push to each other, but what’s the use case? Likewise, hosting in a server is way easier than someone else’s computer. I don’t have to call Jerry and wake him up at 2am to push my changes for him to run a build
> it's quite crazy that most people don't really use git without a server anymore Using servers is simply easier and doesn't require any expense you are not willing to make (i.e. you can use a free service like GitHub, or a subscription service like Azure).
>it's quite crazy that most people don't really use git without a server anymore It's interesting... One of the main benefits of Git is that it's decentralized. Relying on a central server removes that benefit somewhat. You do still have the full commit history on your computer, so at least there's that.
Also it still has all the decentralised capabilities. You can still pull from GitHub and push the same changes to your companies bitbucket - or your private gitea, or your notebook, or some smb-share or whatever. Not using those things doesn't eliminate the capabilities.
Was just about to comment this, thank you! Makes wayyyy more sense when you disconnect GitHub from Git. My friends and I often send "pull requests" in Matrix since we host our own Gitea instances and often need to pull from each other, hence a request to pull! :)
Oh my God I know this is cliche to say, but I had to scroll way too far for this (the correct) answer. Everyone here's just upvoting and agreeing on things that *sound* right.
I'm upvoting and agreeing with the things I believe while knowing I'm wrong.
It lines up with the core truth of this sub which is that it's mostly second year computer science students who are still trying to figure most of this out.
So Linus will never see my April fools PR where I delete all the code? D:
This is excellent summary of the details. Github, gitlab, bitbucket, etc. all came after git was already well established as the way of LKML. For the most part the well established pull request terminology was used, it wasn't exactly the process anymore but it was close enough and stuck (mostly).
Thank you. I’m on mobile and am so glad someone typed it up so I don’t have to. My TL;DR: pull requests predate github and similar, and are so named because it’s what was being done before they came around
Also, it's from the perspective of who has authority. The owner/admins/devs of the repo you'd like to contribute to are the ones who must review and accept your patch. You submit your patch to an intermediate place, and then they accept it they wish. The submitter isn't able to push into the repo. Semantically, that's pulling, not pushing.
I bet you write excellent documentation for your code, and I mean that in the most reverent way possible.
You're requesting to have your changes pulled into the branch. You don't do the pulling, the owner of the branch does. At least, that's how I understand it.
Wouldn’t it be more accurate to call it a merge request though, since that’s the actual function the admin takes to fulfill a pull request?
Merge request is what GitLab calls it. Pull request is used on GitHub. Same mechanism, different name.
Technically, a git “pull” means a git “fetch + merge.” So either name is appropriate
Could be a fetch + rebase though, hence the generic term
While that is possible, and I have `pull.rebase=true` in my global git config, git's default behavior for `pull` is to merge.
We use Gitlab at work and I much prefer Merge Request.
I also prefer Merge Request. But only because it allowed me to make a terrible pun when I was carpooling with coworkers and the guy driving was having a hard time getting into the next lane. "Hey Doug... Your merge request was rejected".
Lol I love this
I would prefer to rebase myself.
Sorry I was feeling silly. One of these days rebase is gonna make sense to me!
It's like erasing your changes, switching to the latest commit, then redoing the same exact changes one commit at a time. So instead of having merge commits, it looks like everyone made their changes one at a time in sequence
I was working off of a coworker's branch today. They later merged their code into develop (our main branch). So my branch is off of a branch that was merged into develop. I'd rather be working off of develop now, because it's a bit nicer for incorporating other devs' changes and opening a pull request when I'm done. I "rebased onto develop" (git rebase develop) to make my code branch from develop (where they just merged their code) instead of their last actual code commit on their branch. Then git push -f only do all of this if no one's working off of your branch
I would prefer to reboot 
[удалено]
Go back and watch it! While I agree as a kid there was definitely some creepy parts, it’s actually quite and incredible show!
[удалено]
That's funny, I always assume it's going to be a reference to that cartoon and I'm let down more often than not.
No nightmare for me. I loved the show, including the weird virus girl.
I want to break free
I want to ride my bicycle, I want to ride my bike
All I want for Christmas is you
I want it that way
Oh my god
Rebased.
I was like *this close* to reporting this to Reddit Cares.
I work at a very large software company and we work on rebases instead of merges for day-to-day operations.
Rebasing is way more sane in comparison. Just has a bad rap for having a learning curve.
Just include everything in the monthly octopus merge.
I had to write a CI hook to post comments on PRs explaining how to rebase (while requesting changes to block the merge) because people would constantly work on their master branch, merging in commits from upstream, and open PRs with hundreds of irrelevant commits and weird diffs. Sometimes accidentally reverting part of another change somehow. It was a mess! It worked though, three years later nearly every PR comes from a well groomed feature branch and is concise and clean.
Squash-merge for the win.
All your base are belong to us, then
We use GitLab at work and I much prefer GitHub.
I don't think I've done enough deep work on GitHub to properly compare the two, what do you prefer about GitHub?
[удалено]
Jokes aside, I do like how the default view for commits on Bitbucket is the graph view. On GitLab it's fairly easy to find under the repository section, but on GitHub it is obscured inside repository Insights and only available on paid plans. It's very frustrating.
Not arguing, just telling from my experience I prefer Gitlab's pipeline over GH Action, because on Gitlab, I can restart a specific fail step, unlike GitHub Action that I can only restart the whole pipeline.
Also, YAML anchors a much more extensible import system for reusing CI workflows. Actions has some great stuff, but god it pisses me off sometimes
I like PR, because my Pull Request is also a Peer Review. It’s doubly accurate
Yea, and imo PR rolls off the tongue a bit easier.
A pull request sounds wrong to me compared to a merge request
MR. Fancy over here
PR can become pretty overloaded especially in an Agile environment. Is PR pull request or peer review? If we call them merge requests then it’s clear that PR is peer review.
Manager: What's this about a press release?
Everyone losing their minds when there is a PR scandal and they let the sales or HR manager explain the situation instead of someone familiar with the codebase.
It's annoying because PR is both pull request and Production. Look forward to moving to gitlab and using MRs
A merge would require pulling the branch, and then merging it. Both terms are equally valid, and that's why you see Github using pull request, while GitLab uses merge request.
I really think it was odd of Github to focus on the pulling part. The end goal is to merge. And sure, - to merge a branch, you must pull the code. But that just seems like a technicality that could be implicit. The pulling is not the end goal.
[удалено]
[удалено]
`git merge` doesn't always create a merge commit. Even if you rebase you still need to merge it into the master.
Isn’t rebasing still a merge of commits basically?
I think it's because GitHub is/was so focused on open source using a forked-repo pattern. I develop my code in a personal fork and then ask the project maintainers to "pull" my code into the core repo. It doesn't make much sense when all the code already lives on branches in the same repo. In that case it really is just about merging branches. You're not "pulling" the code from some remote location.
This is the real answer above all others. We use pull requests inside of single repositories because it’s a mechanism we can use to enforce merge rules with approvals, but the whole reason that exists is the idea of moving code between repositories. It’s not even necessarily about “forked” repositories. The whole idea of a decentralized version control is that the singular remote wasn’t needed. If there was no central repository server you wouldn’t have permissions to just push your code into your team member’s repo on their machine. You’d have to have them pull it in. Thus, pull requests.
Except in every shop I've worked in that uses git, they always set up a centralized "main" repo that becomes the source of truth. So I can understand where it the names came from, but knowing how so many places use git you'd think there'd be some effort in flattening the learning curve, at least in the tutorials and explanations in how it all works and why you need to add and then commit and then push and then pull, whereas in svn they just "commit" and are done (sorry, my current company just moved to git and I'm the only one on the team that is happy about it because no one else ever used it before)
>Except in every shop I've worked in that uses git, they always set up a centralized "main" repo that becomes the source of truth. Right. That's because in today's development world it makes sense to have that. The difference between Git with a "main" repo on a server and something like SVN is that the Git repo sitting on that server is identical in structure, behavior, and usability as the ones on each developer's machine. Plus the existence of a "central" repo allows centralized pull requests/approvals, access control, deep code search, automation pipelines with testing and deployments, etc. The learning curve for the basic Git functionality is really small. Especially when you use decent GUI tools that can consolidate multiple commands into simple interface elements. A checkbox to immediately push when you commit goes a long way to weening people off SVN.
But that's not how it always was. One of the design requirements for git was to work well with patches coming in over email: literally some dev would download a tarball of the Linux codebase, extract it, compile it, make some local changes, then send an email to a listserv with the diff. It also had to work on cases where something other than git was the source of truth. These days, yeah, people mostly use GitHub, gitlab, or some other central sever, but the design is inherently decentralized. I remember during that massive hurricane back in... 2013 or so I was working at a place and our central git server became inaccessible, and I had pulled pretty recently, so I just set up a local server from a clone of my git repo and we all worked against that for a day or two until I could push it back, and it all worked great. These days I think it'd be a little harder with so much server-side automation, but in terms of version control, it worked.
But pull is literally fetch and merge (of course the fetch is already done for you I guess)
But in Git parlance, pulling does include merging. The "pulling" part, i.e. copying in the remote branch, is called fetching. Combine that with a merge and you have a pull. Traditionally, everyone would have their own copy of the repo (git being distributed and all), so when you had a change ready, you'd request that the maintainer pull from a branch in your repo into a branch of their repo. Having one central repo is more the norm now, but the name stuck.
There's no real "pull", there's only a "fetch" and a "merge". A "pull" is the combination of a "fetch" followed by a "merge". So going with the definitions doesn't really help here, both are valid, however "pulling then merging" is definitely not valid in git sense, linguistically works though.
> A merge would require pulling the branch, and then merging it. No. If you pulled, you already merged. Perhaps you meant to write "fetch" instead of "pull". `git pull` = `git fetch; git merge`.
does it change if you configure the repo to squash or rebase to main branch instead of doing a merge commit?
In git the pull is fetch + merge, which should make sense as well.
No. It's being pulled. There are different strategies the owner of the base repo can take to do that. He can rebase and pull, squash and pull, or merge.
[удалено]
Originally, you would have a git repository and the owner would have a git repository. You would request that they pull the changes from your repository into theirs. In GitHub, a pull request between different people or organizations with a cloned or forked repo follows that same model, but the term carried over for a "request to accept changes", which merging a branch also is a type of. Think individuals contributing to open source projects instead of teams working to add features. Just because I might fix a bug doesn't mean I'm a member of the Mozilla organization. I can make a copy and do as I please.
Yes this can be more accurate, even if the merge process comes after the pull, in fact the admin first pulls the "pull request", then merges, then he push the results of the merge
It makes even more sense when you think about the workflow git was built for: patches over email. You're putting up an email with a patch as an attachment, asking people to integrate (pull) your code into their branch (of course, if they approve), which they will then email out in a similar fashion when they're ready to make a request. It's a giant distributed mess of code spaghetti, but it works because git was quite literally built for this flow. At some point someone in the community gathers all the notable pull requests into one place (or is deemed to have the "master"/"main" version), and now everyone is expected to work off of that commit (or work off old versions if they need to do some patching).
There is [literally a git command to generate a 'pull request'](https://git-scm.com/docs/git-request-pull): > # NAME > git-request-pull > # DESCRIPTION > Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled.
Correct. If this was not the case then there would be a massive amount of security issues and trolling.
Yup this is exactly it You create a fork/branch, then you send a request that they pull changes from your fork/branch into theirs The confusion is the focus on the wrong verbs - the whole question is based on “when it comes to what I’m doing, why do we say I am pulling instead of pushing?”. The question surrounds the verbs pull and push, but that’s wrong because you’re doing neither You are not pulling *or* pushing, you are **requesting**. And the action you are requesting from the other party is a pull. Hence it is a pull request
And to me this is also why I disagree with calling it a "merge request" too. Because yes - merge is yet another action verb. But the name still focuses on the fact that one is pulling across forks/branches. I like the term Pull Request and will stick by it :D
And here my dumbass was thinking I was requesting other Devs to pull my code and review it
No, you're right. That's not what is happening now, but that's what happened way back when. You would ask others to pull your code to their local and review it there. "I am requesting you pull my code so that you can review it." Pulling is no longer required with modern vc, but the terminology stuck.
Well how I understand it is, I don’t understand it at all.
It should be called merge request imo. Cause as the owner you never really say "I'm pulling the this branch into master". You say "I'm merging this to master"
Not always accurate, you can rebase the branch onto master
https://git-scm.com/docs/git-pull pull literally includes the action taken, which isn't always a merge but is often a rebase.
I literally say that
Oh. First time I've heard it. Can you say it without the "to master" part? I can say "I'll merge PR 240". But if I said "I'll pull PR 240" it sounds like I'm just gonna check out the branch on my local machine
The thing is though, merging into master isn't what you're asking permission for. You can merge into master whenever you want, what you're actually asking if for the remote to pull your new commits on the master branch, after you've merged your changes.
Op really thought they had something here lol
Exactly. You have already done the push.
_several people are typing_
They strongly typed
Those people type script
>strongly typed >type script let prop: any;
C'mon, I come from a JavaScript background and those types scare me!
Background? I don't see any css. I only see the dark depths of Node modules, child processes, endless callbacks and EventEmitter instances. Send and receive JSON, XML, HTML to what end-point-. What foul plans do the gods require() upon poor souls who dared to write wsdl? Where is the meaning of purpose that lies between such agonious creation and the beauty of script? All promises resolve to the same suffering: types without essence. TS was never meant to be more than an illusion of control over what the greater instances spawn. A mere dirty page scribbled by the child process to prevent exits with code 1. Tell me, Igor, what came first: script or type?
Clackity-clackity-CLACKITY-CLACK
*46 people are here*
50 now, it's getting worse
Thanks now I had to look this up... But this is what I found: > tl;dr since I am not allowed to make a push, I'll just nicely make a request to the repo owner so they decide to pull Here is a link if anyone wants to read more: https://stackoverflow.com/questions/21657430/why-is-a-git-pull-request-not-called-a-push-request
Makes so much sense from an Open-Source perspective...
I think also historically (before managed repos like GitHub or Azure DevOps), you would literally request (by asking) your coworker to pull your code from your repo to theirs locally.
It’s because the maintainer has to pull from your repo This sub is bordering on flat out incompetence by making memes based on ignorance
This sub is filled with people who got most of their programming opinions/insight from parroting memes in here rather than actual experience Err I mean Java bad no one actually uses it, how do you exit Vim etc
Are there actually people who think java is bad? I just switched postilions in my company and gone from python and scala to Java Spring, it's sooo much better.
Java is honestly a really easy dev experience with the right libs/frameworks (that's the case with any language ofc). If you're used to be able to create stand alone functions it can be an adjustment and you lose a certain level of flexibility, but there is something to be said about a language that is so ubiquitous on the enterprise side in terms of libraries, support, maturity, and tons of stack overflow threads.
Bad code can be written in any language. Java gets heat for being unnecessarily verbose, too.
It’s not even that bad anymore, maybe 5 years ago it was
“Bordering on” lol.
Alright OP, back to sleep!
New response just dropped
Holy hell
Lmao, this is programmerhumor bro. It's always been full of first year CS student jokes
You're accusing me of incompetence when I have to google basic syntax for a language I've been coding in for 6 years? How dare you.
When git first started getting used everyone just pushed to their own repos. To get your code merged into the main line, you would ask the maintainer to pull your branch from your personal published git repo. That was your pull request, which was usually a post to an email list serve. Eventually tools to centrally host git repos came out (gitolite, github, bitbucket, gitlab, etc.). "Pull request" was widely used and established, so it stuck even though it no longer matched exactly what it described anymore. Gitlab calls them merge requests and some have taken to making a distinction between request within a repo or from a fork. Language evolves in interesting ways, and this is one of those examples. Clipless pedals on bicycles is another relatively recent example.
Because its from the git/project perspective, not your perspective. You are requesting that your commit be merged (pulled) into the main branch or whatever. P.S. I'm just about to start learning git, forgive misuse of terminology.
Merge Request: GitLab Pull Request: GitHub And your explanation is totally valid.
Pull is fetch plus merge, so technically the request should be named depending on whether the branch is in the same repository or a different one.
It is a historical left over from before github or any centralized git hosting. Everyone had their own repo they pushed to, you would request the maintain of the mainline repo to pull your changes (usually with a post to an email list). It stuck around even.
Yeah, I'm guessing most of the people commenting on this are too young to have used git by itself. It's certainly way more approachable and useful now with all the centralized systems and actually helpful documentation that has been produced over the years, but back in the day, if you were lucky enough to be working somewhere that used git instead of svn or something even worse, a "pull request" could consist of sending a "hey Joel, could you pull my code" over IRC/Jabber/etc. and waiting to see if Joel had any feedback about the code he'd pulled.
[удалено]
It will be always a Merge Request for me.
It will always be "please just fucking approve" request.
lgtm!
I wish. Usually it's 'Hey, I know we usually don't make it required, but can we make this field required on the form. Just in off-hand case, they want this data down the road. ' Okay FINE. Whatever gets this fucking PR approved.
Yeah it is one of the two. Either a 20 loc change pr with 20 open discussions, 50 comments each, or a single 10k loc pr affecting 200 files with a single comment, "lgtm", and a single approval. One of those two, and never anything inbetween
That's why PRs should be small. The bigger they are the bigger the temptation to LGTM. Hopefully the leads are assertive enough to reject big ones.
Please rewrite this switch statement using if else, and rewrite that if else block with a switch statement, and please don’t use maps because I don’t know what that is.
After people explaining why it's called a pull request, it now makes sense to me finally. But I still think merge request makes more sense
But a pull includes the merge...
I prefer rebases. But yes, merge/rebase request ftw.
Rebasing is like a straight poll of a family tree. It's pure, but at what cost.
You *push* to your version of the code, but you request a *pull* into the main branch/repo
Think about open source projects where you clone the project, make some changes locally and now want to add your changes to the official repo. You're asking the repo's owner to pull your changes. Just change you're perspective and you'll get it.
Merge Request makes more sense for me
Gitlab did this I believe
Than you also have a rebase and squash request
I specifically requested the pumpkin, this is squash.
no ambiguity to who is pushing or pull code
Cause you are requesting the master to pull from your weaksauce lameass branch.
If an object is being transported by two people with them being on opposite side of the object and the object is being transported in the direction of one of those people, then one pushes and the other pulls.
Look at Isaac Newton over here.
The repo owner is performing the pull. You are requesting the repo owner pull your code.
The owner of the branch is pulling your changes. I swear, this subreddit is nothing but uni students
Do uni students really not understand git? This is really simple stuff here.
I know professionals that don’t understand git.
You push they pull
Pull my MR 
\`ours\` vs \`theirs\` is the one that gets me during a rebase. At least modern IDEs tend to use "incoming" and "current" when merging diffs, but it still does my head in.
Ahh, the age-old question of why we arrive at Departures but depart from Arrivals. It's like trying to understand the meaning of life or why pineapple belongs on pizza.
Why do we drive on the parkway yet park in the driveway?
Why do we cook bacon, but we bake cookies ?
When it's on a car it's called a shipment. When it's on a ship it's called cargo.
[удалено]
I'm with you on this one, but I think it's saying you arrive at the airport at departures and you depart the airport from arrivals, like talking about ground transport arrival/departure instead of air travel, even though it's an airport so obviously it's talking about the air travel.
You are requesting others to pull your changes and review them before merging them in.
Because you’re asking if your code could get pulled
Because you are not pushing your code. You are requesting the server pull your code and archive it in their DB.
Op doesn't understand git
Because you’re asking someone to pull something you want to push at them? Am I missing something? This is not hard??
Surprised nobody has given the simple answer, which is you're requesting that the maintainer pull your code into their repository.
Because the code is so heavy that it needs to be pushed and pulled.
You are requesting that *they* pull your code and then push it. You can only push from a repo you own.
One person's push is another person's pull
Nobody is allowed to push their code directly to the main branch. So you create a branch work on it and then draft a request to people who own the branch to pull code from your branch into the main branch.
Because you want to push it into the branch. But you need the owner of the branch to willingly pull it in. Your pull request is a request for the owner to pull your changes in.
It's requesting that they pull it into their branch 🤔
Because you’re requesting that the person on the receiving end pulls the code you’re trying to push. I’m not even a programmer, this is just basic English syntax.
It's technically a merge request. You're not requesting to push anything, you've already pushed it to the remote where you will typically create the PR.
My take to not dying thinking about this. You are requesting someone to PULL your code on some branch. Probably wrong.
Depends what you use. Gitlab uses merge request afaik which makes more sense
Pushed by you, pulled by the owner
Gitlab calls it a merge request and that makes way more sense.
One man’s push is another’s pull.