[seadan83]

Multiple at once. Good pointer on `--update-refs`!

I can think of quite a few additional concerns. Overall I think it comes down to how the team wants to handle code reviews.

Personally, I do think if the team is at the level to coordinate and execute on a stack list of PRs, there is little need to incur extra round-trip times for "reviewing" precursor changes and instead focus review time where it is explicitly wanted.

Though, I do indeed like stacked PRs over commit-list because there is more incremental progress, but it does come with some costs. For example, perhaps the last reviewer does not like the overall direction that the cumulative work has led to.

My experience is that at that rate, it's best to let teams decide how they want to operate, formalize somewhat how things are shipped, and bias towards shipping. On the other end of the spectrum, a person quickly glancing at refactoring updates, not having good context on how a given PR fits in - it can almost put into question whether CR itself is entirely a best practice. Hence, I'm a fan of "ship/show/ask". I think it mostly does away with the need for stacking PRs with very little downside (and upside of greater efficiency, CR is spent time reviewing more important code, things that benefit from CR and use the reviewers time well, and makes for a better flow for the author since they can readily merge).