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

201–210 of 308 posts

Re: Stacked PRs are now live on GitHub

#201

Post by progval »

matharmin wrote: post #13

I'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…

Stacked PRs are so hard to implement for software not natively designed for them. Gitlab has been struggling with them too, despite 2.5 years since the MVP (https://gitlab.com/gitlab-org/cli/-/work_items/7473) . It doesn't help they want to do it without making any significant change outside the CLI, or that most developpers just... don't get it.

Re: Stacked PRs are now live on GitHub

#202

Post by Too »

CBLT wrote: post #189
miovoid wrote: post #129

Earlier quoted context omitted.

Why not to make it part of Git project? Such fragmentation adds complexity and vendor locking.

I'm trying to understand what you mean, because it's not obvious to me at all. If you read LKML you'll see stacked PRs has been the norm for years. I'm assuming you want the `gh stack` porcelain into the git cli? We'd first need to add PRs as a porcelain to the git cli for it to make any sense, right?

Gerrit manages stacked changes with standard git tooling, except for the tiny change-id hook. Similar stable change identifier is also what enables Jujutsu to do its magic. Standardizing around something like this would be greatly beneficial, instead a ”gh” CLI is now needed to push a commit.

Re: Stacked PRs are now live on GitHub

#203

Post by jezzamon »

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.

You ideally need a directed graph where descendants can have multiple parents (which JJ supports). If you can't, then the linear tree is just as good I think.

Say you do change A, add a protocol buffer API definition, then implement the server logic (B) and the front end code (C) so that both depend on A but not each other. That can be in a tree. But now you want to add an integration test (D) that depends on B and C. The tree doesn't help you there, and you were better off making it a linear chain by arbitrarily picking one of B or C to be dependant on the other so that you have a code state with all of A,B and C applied to create D on top of.

Re: Stacked PRs are now live on GitHub

#204

Post by brabel »

sunshowers wrote: post #149
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 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…

[dead]

Re: Stacked PRs are now live on GitHub

#205

Post by brabel »

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’ve been using stacked prs for many years, AI did not change anything in that area. The advantage is that you can control what lands in the trunk independently of what a particular review contains, and that you can commit freely without having to later go back and do archeology on past commits to make them look reviewable. The unit of commit and the unit of review is not the same and you shouldn’t try to make them so, they have entirely different purposes.

Re: Stacked PRs are now live on GitHub

#206

Post by shmichael »

nonethewiser wrote: post #198
steveklabnik wrote: post #54

This is one of the biggest changes to hit GitHub in many years. I'm really glad to see something like this deployed to one of the largest forges in the world, hopefully it will expose a lot of developers to workflows that they didn't even know about before. If you buy the idea that stacking produces better software, then this also has the opportunity to really help out quite a few people.

How is this different than creating a feature branch off main then branching off that?

Stack management: automatically rebasing all dependent PRs on any downstack change. Ability to view & navigate the stack in the reviewer UI. Ability to merge a whole stack with one command.

Re: Stacked PRs are now live on GitHub

#209

Post by teiferer »

sameenkarim wrote: post #50
matharmin wrote: post #13

I'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…

We're rolling out a series of bug fixes for the issues with squash merging. There's an internal system we have called CPRMC (Create Pull Request Merge Commit) that is used to evaluate whether a PR is "ready" to merge. This covers everything from mergeability (checking for merge conflicts) to rule evaluations (ensuring that approvals match the potential commit that will be created by merge) and more. This becomes part…

> This becomes particularly difficult when squash merging a stack of multiple PRs

I acknowledge that it is not trivial.

But this is 2026. Many people have solved this in in-house solutions. Every place I have worked at in the last 10 years had solutions in place. Some had wrinkles but it all worked in the end. Github sees itself as the leading provider of solutions in that space and has MSFT backing. Just saying that it's difficult is not good enough, quite frankly. People have been complaining about GH support for this for a long time.

Re: Stacked PRs are now live on GitHub

#210

Post by CalRobert »

OtomotO wrote: post #200
mosura wrote: post #135

Earlier quoted context omitted.

GitHub has been especially bad. Ultimately they have become a monopoly so it is kind of expected.

They are a monopoly in certain regions of the world. Even though I live in a western country, just one of my clients after all these years of being self-employed, uses GitHub. Nobody else would ever use it. And why would they? Especially for proprietary applications.

That's interesting, I get pushback when I suggest anything different and for devs under 30 I've had to remind them that git and github aren't the same thing. This is not to cast aspersions on them, just the state of things in the places I've worked.

Microsoft seems to be running the classic embrace, extend, extinguish playbook on github/git though. When it becomes impractical to join a team's workflow without github specific tooling then everyone will be forced to use gh.

Post reply on HN