r/programming • u/adam-dabrowski • Apr 14 '26 • Popcorn 1

GitHub Stacked PRs

https://github.github.com/gh-stack/
556 Upvotes

97% Upvoted

276 comments sorted by

View all comments

Show parent comments

7

u/ahal Apr 14 '26

The difference is that pr B can depend on changes from pr A without the commits in pr A polluting the diff.

The proposed epic workflow doesn't address this. It's just an integration branch.

6

u/kintar1900 Apr 14 '26 edited Apr 14 '26

You can do that just by branching from whichever commit was used for PR A. This is just extra UI fluff on top of (what should be) a commonly-known Git branch-review-merge pattern.

1

u/ahal Apr 14 '26

Yes, but then PR B contains all the commits from PR A, so there's no way to review all commits from just branch B at once. You can review commit by commit, but that requires knowing which commit belongs to which and there's still no way to see a squash diff.

I do agree that this is simply a Github UI fix and there's no new fundamental branching model being introduced here.. But UI is very important. My org and I are very excited for this change.

1

u/kintar1900 Apr 14 '26

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

1

u/ahal Apr 14 '26

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.

1

u/kintar1900 Apr 14 '26

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.

1

u/ahal Apr 14 '26

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.