[petcat]

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

[vidarh]

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.

[codexb]

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.

[NooneAtAll3]

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

it sounds like you want multiple checkpoints for review parts to happen on, but still only 1 merge in the end

[vermilingua]

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.

[i_cannot_hack]

There's only a limited amount of context and decisions that can be effectively communicated informally without looking at the code. Sometimes it is required that people look at the actual suggested implementation, and when doing so they might spot fundamental issues that had not been found beforehand. The conventional format for doing such a review is a PR.

[radlad]

And thus, you don't have to build on every single unreviewed PR - but often it's quite sane to do so.

[steveklabnik]

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.

[bkolobara]

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.

[Vinnl]

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.

[catlifeonmars]

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.

[eviks]

> Why would I want to build on changes that haven't been reviewed and accepted?

Not to waste time not being able to do anything that depends on those changes?

> git and most accepted development workflows are linear.

Linear like branches easily branching off other branches?