I think the argument against rebasing is spending time polishing a PR to have a cleaner history for one feature that will maybe get looked at during review (rather than the final output) vs also making a PR for a second feature during that same time.

And you can eventually have github squash for you anyway.

Rebase work resulting in atomic commits != squash

You can’t do stacked PRs without merge commits, not unless you really like conflicts anyway.

I have never seen stacked PRs work that well in practice. Two reasons:

- Namely there would be review comments on the first PRs that then cause a cascade of merge conflicts in the follow-on PRs

- Somehow reviewers never seem to like the stack of PRs, my experience is they always react with disdain and/or confusion.

There is the counter-question too, why not stack commits cleanly?

A third reason against, not a good reason, but for many developers Git is super difficult (IMO largely a skill issue, not taking the time to learn basic tools that they need everyday; otherwise I have no clue why software developers do not learn their IDEs and VCS tools very well). Stacking PRs requires some Git skills, a simple feature-branch workflow can be a challenge for many..

Ultimately, I think the solution to stacked PRs is to change review policy to "ship/show/ask": https://martinfowler.com/articles/ship-show-ask.html

In other words, if someone is skilled enough to do a set of stacked PRs, the team likely benefits by letting that person merge the stack on their own when each bit is ready and do a post-merge review instead of pre-merge.

(Side-note, my unsolicited perspective: I'm personally convinced that the benefits of linear history is a magnitude more important than all the other peeves & nits combined between merge vs rebase.)

> - Somehow reviewers never seem to like the stack of PRs, my experience is they always react with disdain and/or confusion.

Are people sending multiple branches of the stack for review at once? It should only ever be the "bottom" branch out-for-review at any time.

> - Namely there would be review comments on the first PRs that then cause a cascade of merge conflicts in the follow-on PRs

This can still happen in the model above of course as you need to make changes to the bottom branch in response to review comments/requests.

However, as I noted elsewhere, `--update-refs` is an absolute god-send in those situations: https://andrewlock.net/working-with-stacked-branches-in-git-...

It reduces a ton of manual work (scaled by how many branches you have stacked!) to one operation.

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

Sure you can! In fact you can do magic on stacked branches with `rebase --update-refs` that you can't do with merge: https://andrewlock.net/working-with-stacked-branches-in-git-...

There's tooling that helps with some of that. I have evaluated StGit for a month or so now, and while it does require that one unlearns some git in the process, it has been handling that sort of situation well.