> Once you have the power to do a bunch of small self-contained changes, you want PRs to consist of one or two commits. You want to build on previous changes without needing to wait for them to be reviewed. Lubeno helps you to do exactly this.

Why would I want to build on changes that haven't been reviewed and accepted? That's a good way to waste my time having to redo something because the foundation it was based on was flawed and got rejected later.

There's a reason git and most accepted development workflows are linear.

I do that a whole lot because most of the time I know the foundation will be accepted mostly as-is, maybe with small tweaks but not major changes.

So I branch of a previous PR instead of development when the changes are related, and continue development, and rebase after the previous PR has been merged.

Usually this leads to less rework and fewer merge conflicts.

Very occasionally it means having to rework subsequent work because the approach was actually wrong, but I'll take that over the hassle of continuing to work from a base I know is already outdated.

Because those changes might depend on those other changes. Git merges aren't linear. They're branched. And PR reviews are meant to just examine the merge of 1 branch back into master. They're not really meant to review multiple steps along the same branch to make it easier to review.

There are so many times where I want to create 3-4 Merge requests that all build on each other along the same branch instead of creating one giant MR but the UI for reviewing them doesn't really work that way.

If you’re getting to the point where you’re submitting PRs if you don’t know whether the foundation of the change is flawed, you have more pressing issues than wasting time in code review fixes.

You can just start a new branch in parallel if you don't need to build on top of the foundation. But if you are happy with the foundation and the next feature requires it, you can also continue working on something else. Jujutsu's automatic change propagation to children can also help if you need to adjust the foundation. For me work is mostly continues, like a flow.

If your PRs are more than one commit, you've already introduced work that builds on top of previous work before it's been reviewed.

Stacked diffs just let you review one commit at a time, rather than requiring a full review of the entire thing, while still letting you see that these changes are related, so you can go look at the full context if you'd like.

This lets you do things like "hey, backend person, please review this backend commit, frontend person, please review this frontend commit" instead of "both of you review this full PR". This can save the frontend person time if, for example, the frontend code passes review, but the backend reviewer hasn't had time to review the backend changes yet. They won't be pinged by the other review.

Often it's very likely that previous ones won't need to change significantly, in which case disposing of having the full context while waiting for that review ends up slowing you down a lot. In those cases, often the main cause of extra busywork is Git administration, having to manually rebase sub-branches, and then losing in-progress reviews on those PRs as well.

Anecdata, but I don’t find myself making major changes to code during review often. That speaks to a deeper problem (miscommunication of requirements, author skill, overly pedantic reviewers, etc).

Also, I don’t have time to wait around for a review to work on other parts of the same codebase.