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

141–150 of 308 posts

Re: Stacked PRs are now live on GitHub

#141

Post by saghm »

miovoid wrote: post #129
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…

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

Presumably because "vendor locking" is pretty much their entire business model

Re: Stacked PRs are now live on GitHub

#142

Post by calumcl »

zxspectrum1982 wrote: post #128
IshKebab wrote: post #94

Earlier quoted context omitted.

> it adds very little on top of what I was already able to do by saying "this is PR 1 out of 7, this is PR2 out of 7 and build on top of the branch that I used for PR1/7, etc". That's literally all it's supposed to do. Make that dev flow less awful so you don't have to say "by the way this PR depends on #123, I will change the target branch when that is merged" and nonsense like that.

Well, then it provides so little they could have not done anything at all as well. Useful stacked PRs would be something that uses AI to split my large branch/PR into smaller PRs for upstream to review. Claude does that for me.

They've provided a skill with their stacking CLI to provide guidance to any coding agent and the Copilot harness now ships with a pr-stack command to do exactly what you're saying for PR splitting FYI: https://twitter.com/_JeremyMoseley/status/208219039710799469...

Re: Stacked PRs are now live on GitHub

#144

Post by mattmatheson »

Game_Ender wrote: post #111
sameenkarim wrote: post #50

Earlier quoted context omitted.

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…

Can you make sure there is good API support for stacks? We use a custom merge queue and we want it to be able to land multiple PRs from a stack at once as separate PRs. Last I checked you had to land a single PR, rebase the stack, land the next and so on. This is very expensive in CI time (and wall clock time), vs simply testing part or all of a stack in parallel then declaring those merged. In essence a robot needs…

Hey there - we worked with Sameen and the team at GitHub over the past month to get support for stacks in our Mergequeue: https://trunk.io/blog/trunk-merge-queue-now-supports-github-...

They do indeed have APIs you can use in your mergequeue, I'm happy to share notes on how we built it so you can add it to your mergequeue.

Re: Stacked PRs are now live on GitHub

#145

Post by [deleted] »

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…

[deleted]

Re: Stacked PRs are now live on GitHub

#146

Post by mattmatheson »

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…

Congrats Sameen and the rest of the team! Excited to see stacks make it into GitHub.

We worked with Sameen over the last month to add support for GitHub stacks into our mergequeue, and I'm excited to announce support for it today: https://trunk.io/blog/trunk-merge-queue-now-supports-github-...

Re: Stacked PRs are now live on GitHub

#147

Post by sfink »

skydhash wrote: post #59
steveklabnik wrote: post #47

Earlier quoted context omitted.

You can't have mac/windows/linux/whatever all locally simultanously. Not every project requires this, but for those that do, it's impossible. Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly" than it is when it's on your forge.

> You can't have mac/windows/linux/whatever all locally simultanously. Why can't you? That's what VMs are for. And even then, most cross-platform codebases have an abstraction layer that rarely changes. So even testing on one platform can raise your confidence very high. > Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly" Again why? I wouldn't care about the dev's l…

Heh, it's a fun reminder that different people work on different things.

Sure, I could load up my build machine with mac/windows/linux/android, with multiple versions of each. Emulating x86+x86_64+arm32+arm64+aarch64+... is also doable, sort of.

But considering that the real CI runs several thousand hours of tests total across all platforms, I think I won't.

Also, my Electron-based IDE needs those 10s of GB to edit text. How can you possibly edit a 1KB text file with less than 1GB of RAM?

Not to mention clangd that needs to do its ultra-important work Right Now so I can invalidate it all with my next edit. That's probably the biggest RAM hog of them all.

Re: Stacked PRs are now live on GitHub

#148

Post by sfink »

andy_ppp wrote: post #143

I’m probably going to ask AI to break up my huge PR into a stack then with sensible names? Probably could be a skill?

https://searchfox.org/firefox-main/rev/878b64a4c024f657de81f...

but note line 111:

> This section describes what to do if you're in a Jujutsu (jj) repository. If the user is not using jj, good luck and try your best.

(The whole skill kind of assumes jj. I think you'd need to make a git version if you actually wanted to use it.)

Re: Stacked PRs are now live on GitHub

#149

Post by sunshowers »

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 workflow, which is simply worse than an amend + rebase workflow. Basically every other review system in existence -- Gerrit, Phabricator, what Google and Meta have internally, the LKML -- works around stacks where people amend and rebase their commits when changing them. All of these have some notion of a "diff", with "versions" that are each tracked separately, and the ability in the review tool to do diffs between those versions. My hope with stacked PRs was that for once GitHub would use this as an opportunity to modernize its review system and bring it in line with all of these other ones. But sadly that just doesn't seem like it's on the cards.

Re: Stacked PRs are now live on GitHub

#150

Post by tabwidth »

mmlb wrote: post #35
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 had that same "what's the point" thought every time I've read about stacked PRs, but recently had an (obvious) epiphany. The benefit is you get CI for each commit! I've always hated fixup/typo/fix tests commits and toyed with having a CI check that enforced ci passing on each commit but this drops that need.

Other side of that though, touch the bottom of a stack and every layer above it re-runs. Stack unwinding, basically.
Post reply on HN