Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are dependent pull requests in Github possible?

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:

  • Pull request 1: Create interfaces: Interface A & B and restructure code
  • Pull request 2: Interface A implementation and Tests (depends on pull request1)
  • Pull request 3: Interface B implementation and Tests (depends on pull request2)
  • Pull request 4: Mixed test of Implementations (depends on 2 + 3)

Is there a way in Github to file all four pull requests at the same time with dependencies?

like image 430
fyr Avatar asked Oct 28 '14 22:10

fyr


People also ask

Can one branch have multiple pull requests?

There can be only one open PR from a given branch.

Can I commit to someone else's pull request?

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).

What are stacked pull requests?

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.


1 Answers

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:

  • To submit 5 dependent pull requests, create a 5-level-deep branch hierarchy and submit each PR as as that branch based on the previous branch.
  • To update review 2 of 5, push an update to branch 2, then do 3 merge operations to integrate the changes into reviews 3, 4, and 5.
  • You need to land all changes at once, since GitHub doesn't support updating the target branch of PRs. In the example, all 5 code reviews were landed as a single commit. GitHub now supports updating the base branch of a PR, so the PRs can be landed one at a time.

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:

  • Instead of breaking up a change into independently-reviewable incremental steps, submit it as a monolithic code review that will land all at once. GitHub still lets you split code reviews up into multiple commits that the reviewer can view, but they can't be approved/landed independently.
  • Try to structure your work so you make changes in unrelated parts of the code, and put them on independent branches that you can use to submit independent PRs. You can still keep a local branch with all changes applied using cherry-picking or other approaches.
  • If you have a change that depends on an outstanding PR, simply wait for the PR to get accepted and merged before submitting the new PR. You could mention somewhere that you have another PR that depends on that one, and maybe that will motivate the code reviewer to get to that one earlier.
like image 196
Alan Pierce Avatar answered Oct 08 '22 19:10

Alan Pierce