One of the nice things about jujutsu related to this is that when you update a branch, it rebases other branches started off of that branch. I often switch to jj if I want to split my work for easy reviewing, and it works great colocated with a clone created with git.
Stacked PRs are now live on GitHub
11–20 of 308 posts
Re: Stacked PRs are now live on GitHub
#12Rejoice, finally a new feature that isn't AI related.
Not AI related, but I plan on having my agents use this heavily so I can review PRs in bite-sized chunks instead of all at once.
Re: Stacked PRs are now live on GitHub
#13I've been using the preview for a bit, and I'm quite surprised to see them expanding the preview with so many unfixed issue.
For example, merging an entire stack is completely broken in many cases: https://github.com/github/gh-stack/discussions/212
You can merge one by one, but if you're using squash and merge, you need a re-approval for each PR in the stack if you require reviews. This makes you lose out on arguably the biggest gain of stacked PRs.
The command line tooling (gh stack) helps to make things slightly less manual, but you still need to be very aware of how git rebase works, the tooling just helps automate it across multiple branches. For example, just running the "gh stack rebase" commands that the UI suggests won't work if your local branches are not in sync with the remote ones, and the tooling won't point that out to you.
I do find the stack UI quite nice. It's quite minimal compared to standalone PRs, but it's enough to show the relationship between them.
(My comments all assume you already have a good reason to stack PRs. This tooling just help to make the workflow easier, it does not give any new capabilities)
Re: Stacked PRs are now live on GitHub
#14Rejoice, finally a new feature that isn't AI related.
I get your point, but it kind of is AI related. The size of PRs since AI has made it much harder to review a diff. Stacking the PRs seems like a response to this problem.
Re: Stacked PRs are now live on GitHub
#15Is that why the menu toggle is the stack of pancakes emoji (U+1F95E)? Whimsy is fine but that change made me super suspicious about what I was looking at.
For a moment, I thought it was a reddit-style account birthday badge
Re: Stacked PRs are now live on GitHub
#16Spicy opinion: a reinvention of commits by and for people who use commits like 'File > Save'.
...but if the end result is more popularity of 'stacked' logical changes, yay anyway?
Re: Stacked PRs are now live on GitHub
#17What's the benefit of this type of stacked PRs over a well-curated set of commits, and reviewing per commit?
I think the bigger problem is that big AI PR's need a different way of reviewing. For example, the order in which the diff's are shown can make a big difference in how easy the commits are to read (e.g., function definition change first, then all call sites, then the tests).
Or maybe we should go to a system where diffs & comments are intertwined, a bit like how "Literate Programming" intertwines code and prose.
Literate diffs / literate pull requests... I haven't found anything like that yet.
Re: Stacked PRs are now live on GitHub
#18I thought 'stacking' PRs was useful in two circumstances.
1. The PRs are across different related repos, so they literally can't be combined into one PR.
2. You want to keep producing work while the first PR is in review. So you stack subsequent PRs onto the same branch. Basically just pipelining.
But this feature doesn't seem to hit either use case, and instead just seems to be a different form of stacking commits into a single PR. The standard advice has always been to make atomic and meaningful commits (using e.g. rebase to tell a nice story for the reviewer). And reviewers can go through commit by commit if they like.
What am I missing?
Re: Stacked PRs are now live on GitHub
#19Stacked PRs have been great, a huge boon for me. I was using it before the UI support, just on the command line. `gh stack rebase` is too useful.
Re: Stacked PRs are now live on GitHub
#20Lately I've seen a lot of people complaining about GitHub downtime, performance and overall quality.
Happy to see something in the right direction. I think they've woken up a bit. Still surprising how slow things can move at big companies.
Companies like Linear, Vercel, Zed and Cursor all seem to be looking at GitHub more aggressively though. I do suspect there will be more competition shortly.