Sending a Pull Request on GitHub Even when the Base Repository You Want is Missing
You want to help out on a large project. You find a Pull Request that someone else is working on and decide you want to help out. You make your changes and are ready to send a Pull Request but to your surprise you find that the fork you want to send your PR to is not listed. What now?
It turns out this is a known limitation with GitHub's Pull Request implementation for network with many repositories. If there are too many forks GitHub filters the list to only include the most popular forks.
I've run into this a number of times, usually when trying to work with the php-fig/fig-standards repository. More often than not, if I want to send changes to someone else's proposal (a very common use case) I'll find that their repository is not listed in the "base repo" selection list:
I've contacted GitHub about this several times. This most recent time I got antsy and started poking around while waiting for a response and came to a workaround on my own. Huzzah!
I received an email the next day stating that the team is "discussing ways to address this particular issue with large repository networks." It also included instructions on the same workaround. :)
The Workaround
It turns out it is pretty easy to get around this limitation with a little URL
hacking. Using my example above as a reference, I can target a PR at any base
repo I want using the following pattern and replacing base-repo-username
and
base-branch
as needed:
https://github.com/simensen/fig-standards/pull/new/base-repo-username:base-branch...simensen:is-hit-is-miss
So if I want to send something to, say, tedivm's Cache proposal, I would
use the following URL since the base-repo-username
is tedivm
and the base-branch
would be Cache
:
https://github.com/simensen/fig-standards/pull/new/tedivm:Cache...simensen:is-hit-is-miss
I've had mixed luck on what actually happens when loading the hacked URL. In at least one case either the "commits" or "files" tabs was missing content on viewing, despite having the correct number of items listed in the tabs. The PR worked just fine, though, so if you see this I don't think there is a lot of reason to be alarmed.
Hopefully GitHub will support this functionality natively sometime in the near future. Until then, this workaround should help people currently stuck on this problem.