alt Hacker NewsPR#1: dough PR#2: toppings
You first send PR#1, then PR#2 on top of the first one.
The diff for PR#1 will show dough stuff. The diff for PR#2 will show toppings in relation to dough.
People can review them asynchronously. If you merge PR#1, PR#2 will automatically target main (that's where dough went) now.
In this arrangement, I use to cross-mention the PRs by number (a link will exist in both). I also like to keep the second one draft, but that depends on the team practices.
I don't understand why you would close the second PR when the first gets merged. It should lose the dependency automagically, which is exactly what happens if you branch correctly.
> The diff for PR#2 will show toppings in relation to dough.
The problem is the diff for PR#2 will show dough and toppings all mixed together. Unless you go into the commits view, but that's super tedious and it's easy to lose comments in there.
It's kind of frustrating because there's very little required to make this work. All you really need is for Github to detect `Depends on #1` like it detects `Fixes #123`, and then a) use the HEAD of #1 as the diff based for #2, and b) block merging #2 until #1 is merged.
It's really not that complicated but I'm not holding my breath.