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.

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.

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.

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.

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).

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

Finally. Something we got

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

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.

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)

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?

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

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.

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.