I have never got a good answer to "can't you just make smaller PRs". This is convoluted tooling (needs its own CLI) for something you could achieve with just learning how git works.

IMO this tool is basically allowing you to do that, it just takes care of the bookkeeping to associate the series of smaller PRs with eachother which is possible today but requires a lot of clicking.

If there is a stack of size n and you make a modification at the first change, closest to the trunk, is there a single git command you can run to rebase the other n-1 branches and ensure they remote branches are updated?

Not a single one, but it can be done with 2.

Assuming you're currently on the most recent branch (furthest from the trunk), `git rebase -i --update-refs trunk` will rebase all the intermediate branches. If you need to make a change to the first branch nearest the trunk, either use `edit` in the interactive rebase, or make a fixup commit and enable autosquash for the rebase. The `--update-refs` flag makes sure that all the intermediate branches get updated during the rebase.

Then, to push them all, something like `git push origin 'refs/heads/yourname/*'` will push all branches prefixed with `yourname/`. It's a bit stupid that one can't just do `git push 'yourname/*'` though.

I agree that a `gh stack` command is not needed, but this feels to me like just a better UI feature for a good git workflow. It literally is about making multiple smaller PRs that build on top of each other.

The question is, why are you not just merging them into main as you go? It's a bit of a smell when you "need" to merge branches into branches. It shows a lack of safety and ease in deployments, which is the real problem to solve IMO.

Because sometimes there are changes that need to land as all or nothing.

Right, so 'just work the way the tool requires instead of making the tool work the way you want'. I would prefer the tool worked the way I want and the way I think of the changes instead.