bye, graphite
Stacked PRs are now live on GitHub
271–280 of 308 posts
Re: Stacked PRs are now live on GitHub
#272This was the feature I wanted the most on Github... until I started using jj. I know that jj isn't for everyone, but for me it's been trivial to see the state of and update all the stacks of branches I have on the go. Not that I don't welcome this feature; I just think I don't need it anymore.
I am confused - I love JJ and stacked diffs with Gerrit and Phabricator, but trying to port that same "each commit gets reviewed individually, and things don't break when a half-reviewed stack gets rebased" workflow to GitHub has been a nightmare, how does JJ help?
Re: Stacked PRs are now live on GitHub
#273I 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…
As I mentioned, this is similar to a workflow we used at Canonical ~15 years ago with bzr-pipeline plugin for bzr.
Except that you tried not to divide it by technical aspect (DB changes vs API vs frontend) bit instead into smaller, semantic full features (we also used a 800/400 line diff limit which helped enforce it).
Re: Stacked PRs are now live on GitHub
#274I don't want this. It's too complicated. Plus it's vendor lock in. Give it time. Soon you'll only be able to push using Github's CLI.
Other platforms have been doing it this way for over a decade, and I've found stacked diffs (with Phabricator and Gerrit at least, not tried the GH version yet) to massively simplify my workflow o_O
Re: Stacked PRs are now live on GitHub
#275I 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…
Thanks for mentioning this. It seemed odd to me, too, so I spent some time trying to work it out. As a reviewer, I'm not sure how I'm supposed to assess database or API changes without knowing how they're intended to be used. And deploying them independently seems odd, too, especially if you need to roll it all back. I think in my ideal world there would be a clean history and I could review a PR commit-by-commit. Bu…
Regarding reviewing commit-by-commit, I actually do believe a branch is a unit of work to be reviewed, as long as it is fully standalone and implements a usecase end-to-end (no matter how small, and small it should be).
Commits on a branch are a tool for a developer, and they will go back and forth a bit as they learn more about it, perhaps explore a path, and then go back on it.
With bzr (Bazaar, since abandoned by Canonical, but maintainers forked it as Breezy), you had a nested history: top-line merges look like squashed merges in git, but you simply do a bzr log -n1 and get to see the next level of commits in each merged branch and you can understand the build process and explore what other things original author tried out which did not work. It is simply a way to get the best of both worlds IMO (it was noticeably slower than git, though).
I did find it hard to get the product and design to adopt a similar mindset of developing a feature iteratively, so it was usually the developer who'd come up with in-between designs and UX flows while they converge to the final design over multiple small branches.
Re: Stacked PRs are now live on GitHub
#276Earlier quoted context omitted.
> They don't. But reviewing individual commits in the GitHub UI is hard. So instead of solving that problem, GitHub developed tooling around a workaround for that problem (targeting a PR at another branch that also has a PR). Expanding reviews to allow per-commit reviews avoids the need for managing additional branches and all the headache that comes with it.
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 main line history reasonably tidy as you can keep the approvals if GitHub does the squash via the UI.
Re: Stacked PRs are now live on GitHub
#277As 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…
Yeah: they copied what people were building on top of Github as a workaround to not being able to change Github
Re: Stacked PRs are now live on GitHub
#278Earlier 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…
> 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 time.
But most of those solutions don't have the number of integrations and rules executions that GH has and that's where the challenge lies.
Re: Stacked PRs are now live on GitHub
#279I think it's telling how long it took GitHub to release a v1 of this feature. Folks have wanted this for a long time. Graphite came along and did it years ago (and I'm sure they pondered whether GitHub would do this). And the v1 is also a bit... basic, and buggy. And I'm surprised there's not clear documentation for agents (given using GitHub stacked PRs CLI won't be in models' training data yet). It does feel like G…
This feature was brought up amongst GitHub for years, possibly even a decade. And it was something that they didn't want.
It was new leadership back in October that decided to build this, so it took them 9 months or so. To be clear, I am not saying this is a long amount of time, they had a LOT of work to do to get it to this point, just being clear about timelines.
Re: Stacked PRs are now live on GitHub
#280dont know why you would use github stacked prs when you can just use ez-stack which has native worktree support and much more extensive functionality, also uses the stacked pr api