Yes, we handle this both in the CLI and server using git rebase --onto

  git rebase --onto <new_commit_sha_generated_by_squash> <original_commit_sha_from_tip_of_merged_branch> <branch_name>

So for ex in this scenario:

  PR1: main <- A, B              (branch1)
  PR2: main <- A, B, C, D        (branch2)
  PR3: main <- A, B, C, D, E, F  (branch3)

When PR 1 and 2 are squash merged, main now looks like:

  S1 (squash of A+B), S2 (squash of C+D)

Then we run the following:

  git rebase --onto S2 D branch3

Which rewrites branch3 to:

  S1, S2, E, F

This operation moves the unique commits from the unmerged branch and replays them on top of the newly squashed commits on the base branch, avoiding any merge conflicts.

That’s how I’ve been working for years now. Does anyone know how this gh stacks work internally? Does it do the same thing under the hood?

I’m conflicted about it, seems like a good convenience, but I wouldn’t want my team to get dependent on an exclusive feature of a single provider

(You're replying to someone from product at GitHub, they're explaining that's how it works there)

We dealt with this headache for 7+ years at my former employer. Thanks so much for this.

We're shipping a skill file with the CLI: https://skills.sh/github/gh-stack/gh-stack

Everyone will have their own way of structuring stacks, but I've found it great for the agent to plan a stack structure that mirrors the work to be done.

Stacked PRs can be created via the UI, API, or CLI.

You can also run a combination of these. For ex, use another tool like jj to develop locally, push up the branches, and use the gh CLI to batch create a stack of n PRs, without touching local state.

Amazing. Though this wasn't super obvious from the landing page or docs I read.

> So, if I have three patches in the stack, and I want to merge the bottom two, I'd merge one, wait for tests to run on the other, merge the second vs. merge just those two in one step

As we have it designed currently, you would have to wait for CI to pass on the bottom two and then you can merge the bottom two in one step. The top of the stack would then get rebased, which will likely trigger another CI run.

Thanks for the callout - we'll update those docs to make it clear multiple PRs can be merged at once.

The CLI is completely optional, you can create stacked PRs purely via the UI.

Also the rationale for having a chain of branches pointing to each other was so the diff in a PR shows just the relevant changes from the specific branch, not the entire set of changes going back to the parent/trunk.

Curious how you're thinking about it?

> so the diff in a PR shows just the relevant changes from the specific branch

That's exactly right.

> you can create stacked PRs purely via the UI

How?

I see from the docs https://github.github.com/gh-stack/introduction/overview:

> When a pull request is part of a stack

How does GitHub determine if a PR is part of a stack? Is it automatically detected so that I don't need to adjust my tooling that already creates chained PRs?

When you're using the UI to open a PR, if you set the base to a branch that has an open PR there'll be an "Add to Stack" option: https://github.github.com/gh-stack/guides/ui/#step-2-create-...

Stacks require users to explicitly indicate that they are opening a PR that should be part of a stack.

It's very confusing that the "quick start" guide says the CLI is a requirement, when it's apparently not. This UI flow is exactly what I want! Thank you!

Wow, that's a lot of events! Hope this helps with keeping track of it all now.

Glad to hear I'm not alone in the frustration! Thanks and let me know how it goes.