That feels like the opposite of what I think stacked PRs are? Like someone will open PR #1 for one feature, and then PR #2 into the PR #1 branch, but it doesn't make sense without knowing the context of PR #1 so that gets reviewed first - and then when that PR gets merged, the second one gets automatically closed by GitHub?
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.
PR#2 will show only what changed between dough and toppings.
If you merge it, it will become part of PR#1. You turned the dependency into a single block.
So, if you don't want to mix, you should merge the dependency (dough) first to main (or whatever is your target).
Codeberg probably also supports the same thing, it's a git thing not a GitHub thing. That's why I'm saying it works exactly as expected. Git alone already supports dependencies, and GitHub just follows it.
To block the merge, you can make a workflow that turns PRs with dependencies into drafts. However, as it is a merge from one PR into another, I don't see the reason to. You can easily de-merge them if you need.
From the looks of it, it seems that you are branching at the wrong point, and creating two PRs to main, one of them containing duplicates. That's not what I suggested.
