How to apply unmerged upstream pull requests from other forks into my fork?

Question

A project on GitHub that I have a fork of has a new pull requests that I want to pull into my fork that the author has not pulled in yet.

Is there a simple way to apply pull request from other forks into my fork? Is there something else here that I am missing?

There is an instruction: https://gist.github.com/piscisaureus/3342247 — Piotr Migdal, Nov 04 '13 at 11:41
Does this reflect on the network graph at GitHub if you use git commands to do it? — ADTC, Aug 01 '14 at 17:53
Might also be interesting to find all the branches too: https://stackoverflow.com/q/47798937/10245 — Tim Abell, Aug 07 '18 at 07:29

score 365 · Answer 1 · edited Jun 20 '20 at 09:12

365

Update: Via Webpage

You can also do this via the github webpage.

I assume, you should have already a fork (MyFork) of the common repo (BaseRepo) which has the pending pull request from a fork (OtherFork) you are interested in.

Navigate to the fork (OtherFork) which has initiated the pull request which you like to get into your fork (MyFork)
Go to the pull requests page of OtherFork
Click new pull request
The pending pull request(s) should be offered. Remember to select proper OtherFork branch too. Select on the left side as the base fork your fork (MyFork) (IMPORTANT).
Now the option of View pull request should change to Create pull request. Click this.

Now you should have a pending pull request in your fork (MyFork), which you can simply accept.

edited Jun 20 '20 at 09:12

Community

1
1

answered Feb 25 '15 at 21:02

Hotschke

9,402
6
46
53

8

Works beautifully. Much simpler than cmd line, and easy to review changes. Thank you. – Alveoli Dec 02 '15 at 18:21
3

I had trouble finding how to get to the "OtherFork" on the UI. To easily get there just modify the url with the github username. i.e. https://github.com/userName/repoName – Charles Dec 17 '15 at 20:28
4

I was not able to see the pending pull requests mentioned in step 4. Instead, I selected the branch that corresponded to the pull request made by `OtherFork`, from the right hand 'compare' dropdown. I then selected the left side as the base fork as described above as was able to create the pull request. – seddonym Dec 30 '15 at 11:38
2

Works unless there is no fork. For example: https://github.com/OculusVR/RakNet/pull/61/files – Milan Babuškov Apr 11 '16 at 10:53
1

The exact words from githubs site may be out of date, but the process is spot on. Super simple - thanks! – kevnk Apr 13 '16 at 20:48
Just for the record if someone opened a PR in one of my projects that had the result of this in its history I'd consider rejecting it because it makes the history hard to follow should it subsequently be merged into my repo. I'm not saying don't do it, but just be prepared to have to do a bit of history cleanup if you get a fussy upstream repo. – Tim Abell Aug 07 '18 at 07:22
This should have been the accepted answer, not only simpler but also more logical than the solution with command line & cherry pick. – leo Sep 22 '19 at 07:39
If you miss `Create pull request` button, make sure you are signed in :) – MartinM Nov 21 '20 at 20:56
but it says that i cant approve my own commits – 0xB00B Apr 08 '21 at 15:56

CharlesB · Accepted Answer · 2013-06-04T06:01:27.203

296

You can do it manually quite easily:

add the other fork as a remote of your repo:

git remote add otherfork git://github.com/request-author/project.git

fetch his repo's commits
```
git fetch otherfork
```
You have then two options to apply the pull request (if you don't want to choose pick 1.)
1. If you don't care about applying also the eventual commits that have been added between the origin and the pull request, you can just rebase the branch on which the pull request was formed
```
git rebase master otherfork/pullrequest-branch
```
2. If you only want the commits in the pull request, identify their SHA1 and do
```
git cherry-pick <first-SHA1> <second-SHA1> <etc.>
```

edited Jun 04 '13 at 06:01

answered May 16 '11 at 19:31

CharlesB

86,532
28
194
218

182

Actually, you shouldn't use cherry-pick, it creates new commits... which in turn will cause confusion if you send a pull request upstream. Instead you should merge just like the pull request is asking to do. You don't need to add a remote either. `git pull URL branchname` – Tekkub May 16 '11 at 20:28
3

@Tekkub: agree, it may be better to avoid confusion with newly created commits. Merge is less elegant in my mind since you can bring other changes from the branch you're merging with – CharlesB May 16 '11 at 21:52
8

Aye, but in this case he specifically asked how to pull the pull request into his fork. Pull == merge. – Tekkub May 16 '11 at 22:10
1

@CharlesB, since GitHub automatically adds new commits on the same branch to a pull request, wouldn't it be hard to get any "other changes" (assuming the requester follows best practices and put the changes on a separate branch from continued development so that all of the commits are relevant), unless what you're getting at is when you want only *part* of a pull request? – neverfox Jun 03 '13 at 20:04
@neverfox absolutely, I edited the answer to reflect this possibility – CharlesB Jun 04 '13 at 06:02
1

You should at least the most important of the possibilities: `git merge`. – JonnyJD Aug 07 '13 at 07:22
Here's how to set up the [pull request branch](https://help.github.com/articles/checking-out-pull-requests-locally). – Tamlyn Jun 10 '14 at 13:28
"eventual commits that have been added between the origin and the pull request", are you referring to when the author of the pull request were to make additional changes to that branch/pull request? – AaronLS Jul 25 '14 at 08:52
5

For those who share my mental glitch, "otherfork" is not referencing the original repo, it's referencing the commit from the fork that *issued* the pull request to the original repo. Ignore the original repo and go directly to the fork that made the pull request. You want to manually pull the commit the pull was referencing and merge it with your own. – Michael Khalili Oct 19 '14 at 13:29
@Tekkub Thanks. I would mention --edit and --no-commit options since they might be handy as well. – crissdev Oct 23 '14 at 15:21

score 85 · Answer 3 · edited Sep 08 '19 at 14:23

85

Like Tekkub said previously, you can just pull the branch in directly. Most of the time with GitHub, the branch is simply "master" on the requesting User's fork of the project.

Example: git pull https://github.com/USER/PROJECT/ BRANCH

And as a pratical example:

Say you forked a github project called safaribooks and there is the following pull request, in the originating project, that you want to put in your fork:

Then, in your fork's cloned project folder, run:

git pull https://github.com/fermionic/safaribooks.git fix-str-decode

edited Sep 08 '19 at 14:23

Tonsic

890
11
15

answered Jul 26 '12 at 18:58

SciPhi

2,585
1
18
19

23

Downside of this is that the branch may have other things in it besides the pull request. Also, you have to look up the proper URL for the pull request author's fork. If you want to use a one-liner, better to use `git pull https://github.com/{upstream/project} refs/pull/{id}/head` instead. – jbyler Oct 20 '14 at 22:45
2

@jbyler If the branch has other things in it, I'm pretty sure GitHub will have updated the pull request with them anyway. – Tim Malone Jul 11 '18 at 03:58

score 30 · Answer 4 · answered Oct 20 '14 at 22:37

Pull requests for the project may come from many different authors (forks), and you probably don't want a separate remote for each fork. Also, you don't want to make any assumptions about the branch the author used when submitting the pull request, or what else might be in the author's master branch. So it's better to reference the pull request as it appears in the upstream repository, rather than as it appears in the other forks.

Step 1:

git remote add upstream <url>

You've probably already done this step, but if not, you'll want a remote defined for the upstream project. The URL is the clone URL of the project you forked. More info at Configuring a remote for a fork and Syncing a fork. upstream is the name you are giving to the remote, and while it can be anything, upstream is the conventional name.

Step 2:

git pull upstream refs/pull/{id}/head

... where {id} is the pull request number. upstream is the name of the remote to pull from, i.e. just "upstream" if you followed step 1 exactly. It can also be a URL, in which case you can skip step 1.

Step 3:

Type in a commit message for the merge commit. You can keep the default, although I recommend giving a nice one-line summary with the pull request number, the issue it fixes, and a short description:

Merge PR#42, fixing VIM-652, support for mapping arbitrary IDEA actions

Also see a [related answer](http://stackoverflow.com/a/18096344/2562319) with a variant that creates a local branch with the pull request in it. And a final variant: you can use `git pull upstream refs/pull/{id}/head` to get the commits into your local repo, then reference them as `FETCH_HEAD` (e.g. `git log ..FETCH_HEAD` to see what's in it, then `git merge FETCH_HEAD`) — jbyler, Oct 20 '14 at 22:51
how would I go about rebasing, so the pull request is at the head & I can avoid a merge bubble? — Michael Johnston, Apr 25 '17 at 18:12
This was the solution I needed, because the pull request author had removed his repo. — jswetzen, Dec 25 '17 at 07:08
Yea this also works for merging an open PR from a repository which is no longer publicly available. — James, Jan 17 '21 at 11:55

score 22 · Answer 5 · answered Nov 18 '13 at 21:50

22

Some more detailed info that worked for me.

My .git/config file for the forked repo looks like this:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        ignorecase = true
        precomposeunicode = false
[remote "origin"]
        url = git@github.com:litzinger/angular-carousel.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master
        rebase = true
[remote "source"]
        url = git://github.com/revolunet/angular-carousel.git
        fetch = +refs/heads/*:refs/remotes/source/*
        fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

Then run "git fetch source", which then listed all the pull requests from the forked repo.

 * [new ref]         refs/pull/54/head -> origin/pr/54
 * [new ref]         refs/pull/67/head -> origin/pr/67
 * [new ref]         refs/pull/69/head -> origin/pr/69
 * [new ref]         refs/pull/71/head -> origin/pr/71

And then to merge in a specific pull request run "git merge master origin/pr/67"

answered Nov 18 '13 at 21:50

Brian Litzinger

5,409
3
23
21

1

I edited my .git/config and added the [remote "source"] lines but for the project I was interested in, and instructions worked flawlessly. I love this answer. – philo vivero Aug 13 '14 at 17:53
3

Excellent related advice can be found at https://news.ycombinator.com/item?id=9051220 and https://help.github.com/articles/checking-out-pull-requests-locally/ hints at this (awesome) GitHub-specific read-only remote `refs/pull/` namespace. – Philip Durbin Feb 15 '15 at 12:52
If you use Smartgit you can see these pull requests (and the closed ones) in the log graph if you add `smartgit.branch.otherRefs=notes;pull` to smartgit.properties as per https://www.syntevo.com/doc/display/SG/System+Properties - you can also merge them from there. – CAD bloke Jan 19 '16 at 08:03
btw, you can also try it on the command line with git fetch source +refs/heads/*:refs/remotes/upstream/* +refs/pull/*/head:refs/remotes/origin/pr/* – lib Jan 12 '17 at 17:55

MindTooth · Answer 6 · 2012-03-11T10:31:34.517

9

What I would do is the following;

git checkout master
git remote add #NAME# #ADDRESS TO REPO#
git fetch #USERNAME#
git checkout -b test_fork
git rebase #NAME#/#BRANCH#

I have now merged the changes into a test branch, named test_fork. So that any changes won't dirty my tree.

Optionally you can use cherry-pick as described above to pick a particular commit if that is more preferable.

Happy travels :)

edited Mar 11 '12 at 10:31

answered May 17 '11 at 00:46

MindTooth

4,992
4
20
15

score 2 · Answer 7 · answered Aug 01 '19 at 20:35

I use a handy dandy script for this. I run the script by typing:

git prfetch upstream

and it gets all of the pull requests from the upstream fork.

To create the script make a file ~/bin/git-prfetch.

The file should contain the following:

#!/bin/bash

if [ -z "$1" ]; then
    echo "Please supply the name of a remote to get pull requests from."
    exit 1
fi

git fetch $1 +refs/heads/\*:refs/remotes/$1/\* +refs/pull/\*/head:refs/remotes/$1/pr/\*

Ensure that your path includes the script by setting:

export PATH="$HOME/bin:$PATH"

You can add this file to ~/.bashrc to make the change permanent.

Now, make sure you add the fork you want to get the pull requests from:

git remote add upstream https://github.com/user/repo.git

And then

git prfetch upstream

score 0 · Answer 8 · answered Aug 01 '23 at 22:49

0

Short answer:

Go to the pull request in original repo and take a look at URL:

The highlighted part in URL is pull request ID.

Run the command:

git pull upstream refs/pull/<pull_req_id>/head

answered Aug 01 '23 at 22:49

Shital Shah

63,284
17
238
185

How to apply unmerged upstream pull requests from other forks into my fork?

8 Answers8

Update: Via Webpage

Linked

Related