Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stacked PRs are now live on GitHub

github.blog

Post reply on HN
Print view View original

171–180 of 308 posts

Re: Stacked PRs are now live on GitHub

#171

Post by charcircuit »

dmix wrote: post #118
shoyer wrote: post #89

When will this support "trees" of pull requests, with dependent changes? In my experience with stacked changes (from Google), it is often the case that changes do not stack up as a linear history. I imagine that would especially be the case these days with parallel coding agents.

That sounds difficult for a human to manage, are we sure we want software to encourage that? (and therefore AI)

Coordinating 2 people working within a single linear stack is unnecessary overhead, even harder for humans to manage. It's easier to let them work off of a shared point individually.

Re: Stacked PRs are now live on GitHub

#172

Post by Groxx »

ptx wrote: post #158
sunshowers wrote: post #149

Earlier quoted context omitted.

I apologize for being somewhat direct but what prior art did you engage with? Why are you making people create a branch for each change in a stack? Why do developers have to create new commits when iterating on the PR? Where is the proper support for interdiffs? What about change IDs? The fundamental issue with GitHub -- really, its original sin -- is that the review model is wrong. It encourages a new commit + merge…

Doesn't GitHub do this already? If I force push the PR branch, the PR shows a message about this with a link to diff it against the previous version.

Mostly. You can't do "show me this commit in the stack before and after the force push" though iirc. And you can't comment on the derived diff, even though that's what you'll be reading during re-review to see what changed.

GitHub constantly feels like features get requested with a one-sentence description, and then people who have never used any other major code review systems go build it without any further assistance or feedback, and eventually it just escapes containment and nobody tells the authors that there's a gigantic pile of bug feedback threads until almost a year later. Ten things get fixed, then another feature breaks out and focus shifts.

Re: Stacked PRs are now live on GitHub

#173

Post by necovek »

I dislike them reinforcing the component approach to delivering work through their examples, like the top screenshot showing "database schema changes", "api changes" and "frontend implementation" as separate branches in a stack.

So really, one does consider full stack a single feature, but unless they are reviewed in one go — which defeats the purpose of stacked branches and pull requests — you can end up landing one and a later review in branches higher in the stack needing changes in the lower branches even if they were already reviewed.

When you instead focus on full use-case per branch, but scope them down, it is much less likely you will need to change branches lower in the stack after they are reviewed.

Another obvious use-case is to do a pre-emptive refactor, though I actually prefer doing a post-refactor after the new use-case has been merged in — it's much easier to know the target best approach when you've got your use-cases right in front of you (or you may hit a similar problem as above).

FWIW, I remember fondly using bzr-pipeline plugin to bzr VCS ~15 years ago to do exactly this.

Re: Stacked PRs are now live on GitHub

#174

Post by sunshowers »

Groxx wrote: post #172
ptx wrote: post #158

Earlier quoted context omitted.

Doesn't GitHub do this already? If I force push the PR branch, the PR shows a message about this with a link to diff it against the previous version.

Mostly. You can't do "show me this commit in the stack before and after the force push" though iirc. And you can't comment on the derived diff, even though that's what you'll be reading during re-review to see what changed. GitHub constantly feels like features get requested with a one-sentence description, and then people who have never used any other major code review systems go build it without any further assista…

The seeming lack of engagement with prior art is so frustrating.

Re: Stacked PRs are now live on GitHub

#175

Post by danpalmer »

As someone who previously used GitHub a lot, and now works with stacked changelists (PRs) a lot, I'm not sure this really changes much.

If there's an expectation that you might merge a whole stack, I think you're aiming for the wrong thing. And it seems like landing the whole stack is the biggest push GitHub are making here. Part of the point is independently reviewable and independently mergable. If you're going to merge in one go then just put everything in one PR and review commit by commit in that PR. The commit by commit review flow used to suck, but since ~2021 it has been fine.

I feel like GitHub have built what users (who haven't used a true stacking system) asked for, not what they actually need to change their workflow for the better.

A great implementation would be asking hard questions like: what's the role of a single commit? Should PRs be single commit only? What's the real benefit here? How do you encourage smaller units of review (because it doesn't look like this does).

Re: Stacked PRs are now live on GitHub

#176

Post by MBCook »

sameenkarim wrote: post #44

Hey from the GitHub Stacked PRs team! Excited to release this more broadly so anyone can start stacking: https://gh.io/stacks Would love to hear any feedback, especially with the UI and CLI. We've got a lot more updates to the PR experience in store! Also happy to answer questions about the design decisions we made. There's a bunch happening behind the scenes, and it's one of the largest launches in GitHub history co…

I tried to look through this earlier.

Am I right this is only available through the CLI?

If so it’s a no go for me and my team. Which is too bad because it looks quite useful.

An addition ability I would love, which is a MUCH bigger feature and I recognize that, would be multi-repo stacks.

My company doesn’t use a monorepo, and I like that. But as we’ve been breaking monoliths sometimes a logical feature touches multiple repos.

Being able to have them all in a stack, each building on the previous logically though in different repos, would be amazing.

Maybe it should have a different name. PR Trains? PR Chains? IDK. But being able to have multiple projects in one logical review is the one benefit of a monorepo I’d like, and if I could get it a different way I’d love it.

Re: Stacked PRs are now live on GitHub

#177

Post by ankit84 »

Stacked PRs are not a new GitHub capability. They are an accessibility. Why so hype?

The underlying stacked PR workflow is unchanged:

1. Create branch B from branch A.

2. Open PR A against main.

3. Open PR B against branch A.

4. Repeat for additional layers.

Re: Stacked PRs are now live on GitHub

#178

Post by ghthor »

teeray wrote: post #43
Okkef wrote: post #17

What'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 w…

It’s the “well-curated” part. Many folks treat commits like video game save points, and find providing any kind of message burdensome (e.g. “fix bug”, “do work”). This alone is fine, but then they can’t be bothered to go back and clean it up with `git rebase -i`, so you end up with a mountain of trash in your git log if you don’t turn on mandatory squash and merge. For these folks, the PR becomes the commit. Stacked…

This is it, but also, because there was no way of asking a reviewer to review a single commit and then merge only that commit out of 2+ commits without a lot of ceremony, work streams had to be completely orthogonal to parallelize anything . Now I can fully develop a sequence of 20 changes (each a single commit) and start getting reviews and merging while still progressing towards the goal. I’ve been doing this for 2years with graphite and more before that manually or in other systems/cultures that actually can review a commit/patch and merge that thing.

Honestly all GitHub needed to do was make reviewing and merging commit(s) from a PR possible and that would also been neat.

Re: Stacked PRs are now live on GitHub

#179

Post by ghthor »

ahepp wrote: post #133
Okkef wrote: post #17

What'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 w…

I don't have experience with the stacked PR workflow and often find myself asking the same questions you are. As far as I can tell, the biggest benefit of stacked PRs over just making a coherent series of commits, is that it might make it easier to start work on your second PR before you merge the first one? With human-in-the-loop coding, that sounds like it could lead to a lot of wasted work if the first PR gets sub…

If you make good commits and each of them is a valuable unit of work; having tooling that can manage rebasing them and creating a reviewable PR for each is super valuable for maintaining momentum and making reviews easier.

Re: Stacked PRs are now live on GitHub

#180

Post by ghthor »

EduardoBautista wrote: post #34
Okkef wrote: post #17

What'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 w…

I feel it's more of a limitation of the GitHub UI. It is much easier to group together reviews and comments by PR than it is by commits.

Yep, this exactly
Post reply on HN