Stacked Pull Requests from the fork to the parent repository

Question

How can the Stacked Pull Requests pattern be used when doing PRs from the fork to the parent repo?

I use this pattern often when we need to split a large feature into small reviewable PRs. In one repo it just requires doing PRs between sub-branches which is quite simple. But I wasn't able to find how to implement this when I want to create a PR between repos.

For example, I want to create a PR that fixes the tabbing order of the Timeline component, but this change depends on the PRs that fix the sideways arrows and menu buttons' focusability. In single repo I would have such PRs dependencies structure:

1. master <- sideways-fix
2. sideways-fix <- menu-fix
3. menu-fix <- tabbing-fix

But the cross-repo PR allows me to only select the master branch as the target. This leads to having the 3 PRs:

1. master <- sideways-fix
2. master <- menu-fix
3. master <- tabbing-fix

And the last PR overlaps the changes from the 2 PRs above which makes it larger and harder to review.

Dicky

Just add a comment on the 2 reviews to start with the first one. Or suggest to do the review commit per commit – Zealous

Thanks, @Ôrel, it sounds sensible to me! I was wondering if there's a way to avoid the human factor and only show what was actually changed in the PR, not the inherited commits, on the Github level. – Dicky

Answer 1

While this is not directly supported, there is since Oct. 2021 a Pull Request Merge Queue Limited Beta in progress (now, Feb. 2023, in GA: General Availability).

It is more to validating different combinations of pull requests identified as “ready to merge” in parallel so that pull requests can merge efficiently and without the typical delays that exist between merges today.

So, not exactly your use case, but close, since you don't have to rebase a PR before it can be merged.

On the client side, you have realyze/pr-train which can help:

git pr-train helps you manage your PR chain when you need split a long PR into smaller ones.

If you have a chain of PRs, git pr-train:

Makes sure all your branches in the chain get updated when you modify any of them Creates GitHub PRs for you with a table of contents

Whitcher