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:
master <- sideways-fix
sideways-fix <- menu-fix
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:
master <- sideways-fix
master <- menu-fix
master <- tabbing-fix
And the last PR overlaps the changes from the 2 PRs above which makes it larger and harder to review.
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