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 the biggest gain of stacked PRs.

The command line tooling (gh stack) helps to make things slightly less manual, but you still need to be very aware of how git rebase works, the tooling just helps automate it across multiple branches. For example, just running the "gh stack rebase" commands that the UI suggests won't work if your local branches are not in sync with the remote ones, and the tooling won't point that out to you.

I do find the stack UI quite nice. It's quite minimal compared to standalone PRs, but it's enough to show the relationship between them.

(My comments all assume you already have a good reason to stack PRs. This tooling just help to make the workflow easier, it does not give any new capabilities)

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 covering almost every service from Actions and protection rules to the CLI and mobile apps.

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.

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 where diffs & comments are intertwined, a bit like how "Literate Programming" intertwines code and prose.

Literate diffs / literate pull requests... I haven't found anything like that yet.

I was wondering why there was a pancake icon in my GitHub menu https://github.com/orgs/community/discussions/203497

Started using the gh stack CLI when I first heard of this feature & really liked it - great tooling. Then got approved for the preview & found the corresponding web UI features incredibly underwhelming.

Pre-approval the CLI tooling effectively enables easier automations around splitting a task into multiple atomic PRs - really great locally but then when you push they just show up as independent unlinked PRs.

Post-approval... they still show up as independent PRs. There's a small nav drop down up top listing the other PRs in the stack but that's it. Literally no meaningful UI changes.

The dropdown also allows you to perform a limited subset if the CLI functionality but this is similar to the ability to edit files in the UI - an optional extra casual use feature that won't be a part of dev workflows: the CLI (or IDE plugins I guess) would be the primary way to perform these actions.

It all left me wondering what the big deal with the preview not being a general release - it's extremely minor optional UI. The stacks cli has been general release since this was announced.

As one of my colleagues said - "only took them 5 years"

Is that why the menu toggle is the stack of pancakes emoji (U+1F95E)?

Whimsy is fine but that change made me super suspicious about what I was looking at.

This is a huge feature if implemented well. Going from big organizations with their own custom-built versions of PR stacking back to vanilla GitHub was a huge productivity hit for me.

Really excited to try this. After using Graphite it's been very hard going back to stack-less GitHub. Hopefully this can make the stacked PR workflow more common and give people an easier alternative to mammoth PRs.

This page is unreadable for me (on iOS). The videos keep autoplaying and making themselves full screen.

One of the nice things about jujutsu related to this is that when you update a branch, it rebases other branches started off of that branch. I often switch to jj if I want to split my work for easy reviewing, and it works great colocated with a clone created with git.

The important question in the age of PR metrics as a yardstick for keeping your job:

When you click merge, does a 3 stack PR show up as 1 PR in the Dx metrics or 3?

Stacked PRs have been great, a huge boon for me. I was using it before the UI support, just on the command line. `gh stack rebase` is too useful.

I thought 'stacking' PRs was useful in two circumstances.

1. The PRs are across different related repos, so they literally can't be combined into one PR.

2. You want to keep producing work while the first PR is in review. So you stack subsequent PRs onto the same branch. Basically just pipelining.

But this feature doesn't seem to hit either use case, and instead just seems to be a different form of stacking commits into a single PR. The standard advice has always been to make atomic and meaningful commits (using e.g. rebase to tell a nice story for the reviewer). And reviewers can go through commit by commit if they like.

What am I missing?

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 (and deploying/testing) separately, which gives me more reliability?

  No more opening a single large pull request that takes forever to review, or splitting work across multiple branches you have to keep manually rebasing.

Well, it doesn't seem like a simplification over dreaded "manual rebasing". And the target branch still moves, doesn't it? So, how are you "saved" from rebasing?

It's like responsibility is shifted from the author to the tool. That has been tried before, and every time it seem to consistently produce a similarly shaped mess in a different area of a process, but with an added bonus of the tool's own problems and restrictions.

Been using it over the last week. Only complaint I had was that `gh stack rebase` was struggling rebasing after squash merges but I got a response that the rebasing had been improved so I'm looking forward to trying that out.

What the difference with just two PR with the second PR targeting the first one??

Rejoice, finally a new feature that isn't AI related.

I have been using it for a while and it has been useful. One feature that I am still missing is to be able to stack PR across repositories. In other words, I want this stack to contains some PRs to the backend, some to the front, and some to ArgoCD in some specific order.

Does it work across forks, or is it same repo only (like gh-stack et al)?

Praise be, stacking is such a better ux for separating out a feature diff into distinct component units and native support makes it easy.

Lately I've seen a lot of people complaining about GitHub downtime, performance and overall quality.

Happy to see something in the right direction. I think they've woken up a bit. Still surprising how slow things can move at big companies.

Companies like Linear, Vercel, Zed and Cursor all seem to be looking at GitHub more aggressively though. I do suspect there will be more competition shortly.

The linked blob post says "public preview". That doesn't mean actually released or live, does it?

I don't see the point of this. Just keep your PRs small.

Both GitHub and GitLab have recently released new stacked MR tech: I guess everyone is submitting giant AI-authored PRs these days, and there's a real need to break them up into human-reviewable chunks.

Both are an improvement (GH's seems a little better, with their one-button merge that GL lacks) ... bit both are so incredibly "meh".

When are we going to see the major hosts give tools designed to help facilitate human code review? Simple example: lets say I want to leave notes in my PR (MR on GitLab). I can use the review comments to do so, but then I have a million comments to resolve at the end before I can merge, my comments look just like the reviewer comments (with extra UI for replying that's unecessary), etc.

It'd be so easy to just have a "sign post" feature to let authors annotate their code before reviewers review it ... and nobody offers this, or any other features focused on actually helping humans review. It's all just new command line features that save a bit of rebasing (which Claude can do just fine on its own).

Spicy opinion: a reinvention of commits by and for people who use commits like 'File > Save'.

...but if the end result is more popularity of 'stacked' logical changes, yay anyway?

I must be in a minority of some kind. I still think stacked PRs are the devil and a band-aid for org and process issues.

Lol, maybe they should first fix large PRs crashing/freezing UI.

Finally. Something we got

Another reason that increases the possibility of github’s outages…

[flagged]