Selectively importing other people's pull requests in your own Github fork

Question

Ok I haven't find a better way to title my question. Explaining the scenario is easier. But remember this is a Github question, not a Prototype-JS question (please don't add the tag for me)

The scenario

I'm working on a Prototype-based web application. I found that 1.7.1 (no blame to the author) has a few bugs that are annoying for us. All these bugs do have, fortunately for us, a publicly available fix through a pull request that has been accepted into the master branch.

My boss and I discussed about the choice between patching Prototype 1.7.1 for each incompatibility we find and we agreed that using the "development" version in a soon-to-be production application is not the best choice, so our idea is to patch our version of Prototype.

I am responsible for this. Since I want to track the changes my company applies to Prototype (even if I'm the only who'll touch the JS file), I want to do it in an efficient way that can be left to posterity.

Github allows you to fork any project into your own workspace so you can play with it as much as you wish. I would like to keep track of the patches I import into Prototype by actually linking them to existing pull requests made to the original project.

The general question

Given a generic open source project on Github that I have forked, is there any way I can find a pull request, submitted to the original branch, and choose to "import" it in my own fork (given that the files should be diff-compatible) so that it will be applied to my branch?

Of course, this allows me, over time, to keep track record (with comments and discussions) about what PRs I chose to import in my branch and which I didn't.

Answer 1

Given a generic open source project on Github that I have forked, is there any way I can find a pull request, submitted to the original branch, and choose to "import" it in my own fork (given that the files should be diff-compatible) so that it will be applied to my branch?

Yes. Here's how I would do it:

1. Fork the repository to myaccount/project
2. Clone myaccount/project locally
3. Use git remote add [remote name] for each of the remotes that have fixes you want to use.
4. Run git fetch --all to download everything
5. Use git merge --no-ff -m [remote-name]/[branch-name] to merge in the changes from each Pull Request that you want to include in your fork. --no-ff creates a merge commit for audit-ability and -m let's you specify the message in your editor (so you can include a link to the Pull Request in your merge commit).
6. Once you've made the merge, you can use git push to update your fork on GitHub with the various Pull Requests that you've merged in.

Answer 2

My workflow for selectively adding pull requests is as follows:

1. First make a fork.

2. Then clone the fork locally.

3. Apply patches from Pull Request's.

   • So for instance if your pull requests is on a url like :

   https://github.com/mafintosh/peerflix/pull/188

   • You can create and download manual patch files from the url like so :

   https://github.com/mafintosh/peerflix/pull/188.patch.

   adding .patchto the url creates a patch file on GitHub.

So the workflow becomes like :

$ wget https://github.com/mafintosh/peerflix/pull/188.patch

$ git am 188.patch

If you want to test it on a branch before applying to the master

then the same rules apply to it as applying any other patch.

1. Create a Branch.
2. Apply the patch 
3. Test the Patch.
4. Merge to master.

Answer 3

I found other two ways.

Since PRs come from a branch in a fork, I can create my own Pull Request on my local clone/branch starting from any author's source branch. This is usually easier for edits made via Github web UI, because Github automagically creates a patch-x branch everytime you edit files from UI. This is basically what I can do from console as @johndbritton suggested, but done from the easier UI.

The best approach way is to use git cherry-pick to take the commits manually. If commits are stashed, I can luckily pick a single commit.

For example, if I choose a PR I like, I can use git cherry-pick [commit] for each commit done into the PR, fixing possible conflicts that may arise