Why is a git 'pull request' not called a 'push request'?

Question 1

If you have a code change in your repository, and want to move it to a target repository, then:

"Push" is you forcing the changes being present in the target repository (git push).
"Pull" is the target repository grabbing your changes to be present there (git pull from the other repo).

A "pull request" is you requesting the target repository to please grab your changes.

A "push request" would be the target repository requesting you to push your changes.

Question 2

When you send a pull request, you're asking (requesting) the official repo owner to pull some changes from your own repo. Hence "pull request".

Question 3

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

Who can push code to a repository?

Should anyone (possibly evil or uneducated or unknown) be able to come and say here I just pushed this to your master branch and messed up all your code HAHAHA! ?

Surely you don't want him to do that. By default a safety net is set so no one can push to your repo. You can set others as a collaborator, then they can push. You would give such access to people you trust.

So if you're not a collaborator and try to push, you will get some error indicating you don't have permission.

So how can other developers push to a repo they are not given permission to push?
You can't give access to everyone, yet you want to give others an outlet/entry point so they can make 'a request to the repo owner to pull this code into the repo'. Simply put by making the repo accessible, they can fork it...make their changes in their own fork. Push their changes to their own fork. Once it's in their in their own remote repo:

They make a pull request from their fork and the owner of the upstream repo (which you can't push directly to) will decide whether or not to merge the pull request.

To explain it from a different angle:

pushing is for things you don't need anyone's approval e.g. you can always push to a feature branch that you've created yourself and have been committing to.

_{While you can create a pull request between two branches you've created yourself and can push onto. You almost never do that.}

_{I've done that though when I was working on a big feature and already approvals on my pull request, but needed to make a tricky change, so I created a PR against my existing branch.}

If you then need approval, then you don't want to push. You want others to:

review your branch
give you approvals
fetch your branch
merge it with master

(3+4 = git pull)

Also a semi-related question I recommend reading What exactly happens in a git push? Why isn't a git push considered just like a git merge?

Question 4

Pull Request: I Request to you to Pull mine.

Question 5

I'm afraid that most of these answers address the question What does 'pull request' mean? or What would 'push request' mean? rather than the OP's question: Why is it called a pull request and not a push request?

Normally this sort of question-replacement is acceptable, but in this case it is clear that the OP knows the answers to these replacement questions, so answering them is not very helpful.

Only the people at GitHub that coined the term know for sure. However it seems evident that this terminological choice reflects something like the following viewpoint concerning the phenomenon of "changes coming in to a repository from outside": The maintainer does the action (pull).

However, a request is also an action, and the doer of that action is not the maintainer but rather the submitter (who has done even more action, namely work). Thus the term 'pull request' creates confusion about who the agent is. Ultimately the confusion arises because of the recursive nature of a request: A request is both an action by a primary agent and a request for a future action by a second agent.

The situation is quite analogous to now-common linguistic constructs like "we built our house" (used in place of "we paid someone else to build our house"), in that responsibility for the primary action is shifted from the obvious original agent to a secondary agent fulfilling a managerial social role.

One might conclude from this that the reason for the terminological choice is legitimization of the viewpoint that managerial work is first-class labor. Moreover the reason for confusion about this terminological choice may be that non-manager workers naturally have a different viewpoint.

Question 6

I want to push something to someone else's repo.

I do not have the permission to push (or pull, for that matter).

The owner/collaborators has permissions. They can pull as well as push. I cannot push.

So, I request them to perform a pull from me - which indirectly means that I am requesting them to accept my push.

So, no request for push. Only for a pull. And for acceptance of a push.

Hence, a 'pull' request. And not a 'push' request.

Question 7

It's the word "Request" that is key in these actions. You could also think of it as saying "I have a request for you to take my work, do you accept?" - "A Pull Request".

It's slightly confusing at first, but makes sense eventually.

Question 8

To understand this better and remember it forever, you need to picture it.

Picture a big, living tree {as your repository}. The tree is too sturdy for you to push a branch into in or add a new part into it {symbolizes creating a new branch or you pushing code in it}, instead you must ask the tree to pull a branch into the trunk or have the changes from you.

The term “pull requests” comes from the distributed nature. Instead of just pushing your changes into the repository (like you would do with a centralized repository, e.g. with Subversion), you are publishing your changes separately and ask the maintainer to pull in your changes. The maintainer then can look over the changes and do said pull.

So you basically "request" the guys with writing access to the repo you want to contribute to, to "Pull" from your repo.

Pull requests let you tell others about the changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch. Github Explanation

Question 9

A pull request is generating a request asking the repo to pull your changes.

Question 10

It's not only about subjective and objective. It is also logical to say "I request to push" if it is actually a push operation lying behind.

The major reason is that you cannot push to others' repo. Instead, you have to request them to pull your branch.

So, why doesn't GitHub allow you to request to push? Intuitively, this kind of approach also makes sense if the managers are able to choose to accept or refuse my push, just as how they choose to accept or refuse to pull my repo.

Let's look at push first. Say, there are two repos, A and B:

repo A：  repoB：
  b        c
  |        |
  a        a

A and B have commit b and c on commit a, respectively.

Then you push from A to B. There are two kinds of results.

You git push and fail. Because A and B conflict.
You git push --force and success. However, commit c is gone. It becomes

repo A：  repoB：
  b        b
  |        |
  a        a

This is not what you want to do, right? So you need to do it other way.

You have to eliminate the conflications before a push. Say, you have to pull the upstream repo first and get

repo A：  repoB：
  d
  |\
  b c      c
  |/       |
  a        a

And then you are able to push.

This is how a push request system looks like: contributors handle the conflictions first and request to make a push operation to change the upstream repo. Maybe it seems neat now. The manager of the upstream repo can choose to accept or refuse contributors' push request. Everything works.

However, it only works if there's no other push request.

Say you have just make a push request after pulled the upstream branch and handled the conflictions. You think you are done, but no, in fact. You surprisedly find that the owner of the upstream repo just made a new commit e, when you were pulling codes. Now, the situation becomes:

repo A：  repoB：
  d        e
  |\       |
  b c      c
  |/       |
  a        a

OK. Now you have to pull the new commits to your repo again and make a new push request. And don't forget that there could be some new codes commited to the upstream... Theoretically you may have to loop forever.

And empiracally, you may finally make a well done push request with no conflication. Congratulations, but there are hundreds of push request. If the owner accept another push request first, you have to pull and push again.

Consequently, to make a contribution work neatly, the requested operation must have two parts:

Eliminate conflictions.
Combine branch.

And it must be done by the owner. Otherwise, the owner must:

Approve a contributor's new code.
Approve the contributor's way of eliminating confliction.

But just as the example, there may be some more conflictions introduced when the contributor is eliminating conflictions.

So, pull operation is naturally the choice. That's why there's pull request but no push request.

Question 11

I think its a silly terminology because I want to think that I want to PUSH something to you and not thinking vice versa asking someone else to pull mine addings. Therefore it should be changed into PUSH REQ. since I'm the active part. The arrow goes the other way starting with me and not the Goofy in the other end. IMHO.

Question 12

Think This way. Local repository vs Remote repository.

When you Push from Local. (git push) - in other words, the Remote repository is Pulling codes from you(Local).

You are requesting something. So, ask your self,

Do you want Remote repository Pulling codes from you? - Pull Request.

Question 13

A git pull means I am pulling from the repository.

A git push means I am pushing to the repository.

A pull request would naturally follow that I am asking the repo owner that I can pull from their repository, right?

Wrong, a pull request means I am requesting to (essentially) push to a repository.

The supposed logic behind this is that the repository is now the owner of the command essentially. But if this is the case then it would follow that retrieving code from a repository would be enacted by a git push. Because if the repository is the owner then they are solely responsible for pushing the code out to you. But no. Inconsistency is key.

The accepted answer states that "pushing" makes it sound like you are forcing the changes upon the repository, but that makes zero sense because you lose sight that it is a REQUEST. A request, by its very nature, is NOT forced upon anything.

Question 14

Think from sitting in the shoes of the repo side !! Pull request - This means, Git will say to the repo, that you have something outside to get in, so from the repo point of view it's a pull, So it's a pull request.

Question 15

Any terminology that needs a paragraph of explanation goes to show that the terminology is not intuitive and has complications or one-sidedness behind its choice. There are a lot of well written explanations above so I won't add further to it but here is my commentary on my frustration with the terms push and pull in git.

Consider normal labels of Push and Pull on a door.

Its interpreted from the eyes of the person who is about to operate the door.

If it says Push, the person will "push".

If it says Pull, naturally , there is a knob that will be used to pull the door towards oneself.

Now imagine if gitHub manufactured doors and wrote "Pull" on a door simply to be pulled from the other end and not your end ( so in a way its Push in normal world!). You would then engage your mind to counter-act the intuitive thinking and translate the door pull to a door push.

It is that sort of thinking that is leading to this confusion.

The system 1 of our brain which relies on intuitive , primary interpretations would enter a conflict zone.

I have simply chosen to accept this anomalous definition of git Pull and Push requests and remember it as one of the many exceptions once comes to terms with in life and move on.