Comment by gaigalas

Comment by gaigalas 2 hours ago

> So frustrating that Github doesn't support such an obvious workflow.

It kind of does.

I used this a lot in several jobs to work in dependent tickets in advance. Just make another branch on top of the previous (a PR to the other PR branch).

People could review the child PR before the parent was merged. And it requires some less than trivial git knowledge to manage effectively, but nothing extraordinary. Any solution for stacked PRs based on git would also require it (or a custom tool).

I think I'm on their side on this one. From git perspective, it works just as I expect. Something else probably belongs to JIRA or project management instead.

sevenseacat 2 hours ago

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?

Reply View 1 reply

gaigalas 2 hours ago

PR#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.

Reply View | 0 replies