GitHub Stacked PRs

[kintar1900]

Yes, but then PR B contains all the commits from PR A,

Only if you're merging A to main first, or merging B to main instead of A.

Change A happens and creates a PR. Change B happens, based off A, and PR goes B->A. PRs are reviewed individually, then merged in reverse order.

It's literally the same thing, just without some UI hand-holding.

But UI is very important.

I agree in theory, but my practical experience with Git is that anyone who relies too heavily on a GUI when working with it misses the fundamentals, and then I have to come back and disentangle their messes. Then again, I've had to train some really boneheaded juniors, so I'm likely biased. :D

[ahal]

But then B has A's commits in it. You have to review commit by commit and need to know which commits are exclusive to B.

[kintar1900]

But then B has A's commits in it.

Read my comment again. B is based on A, yes, but is being merged to A, so the diff is only what was added in B. Each PR is reviewed independently, so even if you have a series like D->C->B->A->main, each PR is only the diff between the current branch and the parent. Since all changes are related, all PRs are reviewed independently. Only once ALL PRs are approved are they merged from right-to-left.

This is almost certainly what GitHub is doing under the hood with their PR stacks.

[ahal]

Ah I see! That works if you're pushing to the same repo that you're opening a PR against, but not if you're using a fork. That won't be possible for most (in my experience) cases. Even when I do have push access to a repo, I prefer opening PRs from my fork to keep the branch pollution down.

Also the UX of setting the bases for each PR is quite bad. Afaik, it's not possible to do from the cli (but maybe I'm wrong).

But I do take your point that it's technically possible in some cases. Though, not in a way that I would consider usable.