Currently I am working on a really big pull request. In order to keep code-reviews somehow manageable the idea was to split the complete pull request in isolated parts, which however depend on each other.
An example would be:
Is there a way in Github to file all four pull requests at the same time with dependencies?
There can be only one open PR from a given branch.
You cannot add commits directly to User B's pull-request unless you have write access to User B's fork. You can, however, make local additions to the pull-request, by just fetching the pull-request branch into your own local repo (assuming the url for B's fork is public).
StackedPRs lets you split your Pull Request into multiple, interconnected Sub-Pull Requests. The Pull Requests are managed as a Stack where each Pull Request is based on the branch of the previous. Each PR contains a minimal scoped change making it easy to review.
As far as I can see, this is impossible, and in my opinion it's one of the major downsides of GitHub compared with other code review tools. Gerrit automatically sets up dependent code reviews when you push commits that depend on each other, and in Phabricator it's more of a pain, but still possible.
It's also good to keep in mind that there multiple ways that people use GitHub PRs. The normal open source collaboration way is to fork a repo and submit a cross-repo pull request, but in other cases (e.g. within an organization), you might submit pull requests for diffs all within the same repository. I think within a single repository it's more reasonable to get something along the lines of dependent pull requests, since you can set up the commit/branch structure within that repo.
Here's a blog post that describes how to get some advantages of dependent pull requests, which I think requires all commits to be in the same repo: http://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/
A summary:
That approach seems to work ok for giant changes that are best reviewed in smaller pieces (although maintaining an n-level-deep branch hierarchy is a pain compared with something like git rebase -i
), but it doesn't really allow for a "code review pipeline" where you can have dependent diffs in different stages of review and can land earlier ones as they're reviewed.
Some other internet resources that seem to also call out the limitation:
https://www.quora.com/Is-there-a-good-system-for-adding-multiple-pull-requests-to-GitHub
https://muffinresearch.co.uk/how-do-you-deal-with-dependent-branches-on-github/
My understanding is that people using GitHub PRs generally just try to structure their workflow to not rely on dependent code reviews. Some examples:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With