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

291–300 of 308 posts

Re: Stacked PRs are now live on GitHub

#291

Post by andrewaylett »

cube00 wrote: post #276
atq2119 wrote: post #140

Earlier quoted context omitted.

The sad fact of life is that too many developers are used to pushing PRs with unprincipled commits, and relying on squash merges. The approach that GitHub chose can show those people almost immediate benefits, which is surely the better path towards adoption than trying to reeducate everyone to adopt a development flow based on clean rebases. And for those of us who do prefer clean rebases, the thing they built is st…

> The sad fact of life is that too many developers are used to pushing PRs with unprincipled commits, and relying on squash merges. We couldn't organise our commits once the PR review started because reviewers would complain they couldn't easily determine what had changed between rounds of reviews. If we tried to organise them after review then approvals would be stripped so squash was the only way we could keep the…

GitHub will now maintain approval if a rebase doesn't result in a changed diff. Small things :P.

Re: Stacked PRs are now live on GitHub

#292

Post by rbanffy »

I used something similar to this while working for Canonical and I found the idea confusing, the tooling (2014, IIRC) brittle, and the experience overall frustrating. I would never encourage that as a solution to any problem.

The most important thing about tooling is to keep it conceptually simple. The fewer moving parts you need to pay attention to, the more brain cells you can devote to solving your problem.

Re: Stacked PRs are now live on GitHub

#293

Post by teiferer »

Daishiman wrote: post #278
teiferer wrote: post #209

Earlier quoted context omitted.

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

> 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 t…

Again, it's by no means trivial. But in the last years we as an industry made private space travel viable, created self driving cars and made chatbots that can explain humor. Not being able to do stacked PRs in this day and age by the prime company in this area is just .. well you got the point.

Re: Stacked PRs are now live on GitHub

#294

Post by sunshowers »

Degorath wrote: post #288
sunshowers wrote: post #214

Earlier quoted context omitted.

GitHub has a chance to get a generation of developers on to better coding practices. LLMs make it more feasible than ever to maintain high-quality patch series/stacked diffs — they can take care of all the mundane things like rebase conflicts for you. If I were in charge I would take this responsibility very seriously. I guess the next best thing would be to port spr to this. (Probably time to start looking at this t…

Not sure if it makes you feel better, but it seems there's at least a few startups trying to get a jujutsu-native forge going, by people who have seen and used the way Google's (and other big tech's) systems work.

Indeed, and I happened to have been part of the creation story for one of them :) https://lobste.rs/s/ghdv6w/i_see_future_jj#c_nx6flj (not otherwise affiliated, though)

Re: Stacked PRs are now live on GitHub

#295

Post by lukaszkorecki »

dml2135 wrote: post #282

I didn't see the appeal of bespoke PR stacking tools when it was the headline feature of Graphite, and I still don't see it now. Stacking PRs is useful, but I haven't encountered issues with the ergonomics of just using normal git operations to do it. My stacking workflow is roughly: - Open the first PR from `branch-1` against `main` - While waiting for a review on that first PR, if I need to build on subsequent work…

That's how I worked but it gets tedious for reviewers because there's no easy way to navigate the stack. In the end, I vibe coded an internal PR stacker which stores stack data using `git notes` (allowing multiple people to work in a stack) and updates PR description with stack navigation. It uses merge, rather than rebase because history is not that important (final code is).

Re: Stacked PRs are now live on GitHub

#296

Post by DreadY2K »

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…

How long until support gets added for repos with merge queues? I'd love to use this at $WORK and so would my coworkers, but we can't turn off the merge queue so we can't use stacked PRs until they can mix.

Re: Stacked PRs are now live on GitHub

#297

Post by alepar »

radicality wrote: post #237
necovek wrote: post #173

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…

At Facebook (i left >4 years ago) we used Phabricator where shipping stacked changes like this was table stakes. I still miss it. Some few random points, not really organized, i'm sure i'm forgetting bunch more benefits: * I often used it as a way to make reviews significantly easier for the reviewer. If I split something more complex into smaller units where the small change seems obviously correct, it's much more l…

> it's much more likely i'll get a faster accept than with a very large change.

I do agree the above is true. And maybe it's just me, but it feels like I'm kind of cheating if I stack PRs to get a faster approval. Because when one reviews some dangling code without the context of how it's going to be wired in, they can't really tell what the blast radius will be and consequently what bar they should hold the code against (e.g. performance, security, etc). In these circumstances, usually the most one can do is raise some stylistic nits (which to be fair PR process often degrades into anyway) and move on.

Re: Stacked PRs are now live on GitHub

#298

Post by mahmouds »

Insimwytim wrote: post #23

I feel like many people (and industry in general) complicate things unnecessary. Stacked pull requests break large changes into small, reviewable pull requests. That's how pull requests are supposed to be, no? If yours aren't that - you ought to rewrite them. With stacks, you can independently review and check each pull request, then merge everything together in one click. Why would I want to do that instead merging…

This. I don't even GitHub-style pull requests. A mature, big and complex project like the Linux kernel is still being (happily) developed using small email-based patches. I really appreciate the decision made by Drew Devault in SourceHut https://man.sr.ht/~ireas/guides/contributing.md> to follow this effective yet simple way of managing contributions. GH PRs encourage a bad habit of making large, complex and unrelated changes in a single PR (or even one commit). Mainly bad because it makes the review process overwhelming and inefficient.

Re: Stacked PRs are now live on GitHub

#299

Post by Degorath »

eddythompson80 wrote: post #290
Degorath wrote: post #286

Earlier quoted context omitted.

Jujutsu makes the author-side of it all fairly nice, indeed. But the reviewer-side has been so horribly abandoned by github that it has been frustrating me for a long while now.

A JujutsuHub.com business opportunity presents itself. How many tokens do you have?

Already working on that!

Re: Stacked PRs are now live on GitHub

#300

Post by Degorath »

sunshowers wrote: post #294
Degorath wrote: post #288

Earlier quoted context omitted.

Not sure if it makes you feel better, but it seems there's at least a few startups trying to get a jujutsu-native forge going, by people who have seen and used the way Google's (and other big tech's) systems work.

Indeed, and I happened to have been part of the creation story for one of them :) https://lobste.rs/s/ghdv6w/i_see_future_jj#c_nx6flj (not otherwise affiliated, though)

That's really cool! I tried getting on board with ERSC, but the timezone difference proved too much :(. At least it gave me the kick to try and build my own company, though!
Post reply on HN