undefined

points

[-]

Those could just be individual commits on a branch. Why does it need to be a stacked PR? That concept really only exists within the interfaces of these kinds of tools.

by andrewaylett1 hours ago|

parent|

[-]

They don't. But reviewing individual commits in the GitHub UI is hard.

A set of stacked PRs is exactly the same as a line of commits. The only difference is the UI, but the UI is the important bit here because lack of UI is what's stopping folk from doing that today.

Even when I've developed my changes as a stack of commits, I'll feed them to my team one commit (and one PR) at a time so they're easier to review — and I discovered that GitHub had turned on stacked commits UI because for one particular project I'd manually created a set of PRs in advance (with the right bases) and GitHub offered to create a stack out of them.

by 4lx871 hours ago|

parent|

[-]

> They don't. But reviewing individual commits in the GitHub UI is hard.

So instead of solving that problem, GitHub developed tooling around a workaround for that problem (targeting a PR at another branch that also has a PR).

Expanding reviews to allow per-commit reviews avoids the need for managing additional branches and all the headache that comes with it.

by esafak1 hours ago|

parent|

prev|

[-]

They could but they don't belong together. A PR should be about one thing. Refactoring one module for another's sake should be done in another PR. If not for reviewing, for revertability, and future debuggability.

by kazinator2 hours ago|

prev|

[-]

I certainly don't want to see that in a one commit. A PR has one more more commits, though.

The commits in a PR are already a stack of patches, and so PRs are already "stacked" as they are.

If feature X depends on the refactoring (cannot be rebased on the un-refactored upstream), it's part of the change; you can't just merge the feature and not the refactoring.

If the two are separable that way then, sure, it makes sense to ask for them to be separate PRs.

by Insimwytim2 hours ago|

prev|

[-]

I do that too. I do introduce changes in separate PRs. They could be related to the same problem and referenced accordingly.

  and the changes depend on each other so I can't open multiple independent PRs

Why? Is it a technical restriction? Tightly coupled architecture is not the best solution anyway.

by malcolmgreaves2 hours ago|

parent|

[-]

A refactor and then a feature implemented on that refactor is tightly coupled by definition. It would not make sense to implement the feature and refactor independently, because you’d be wasting time implementing a feature that you would have to refactor again.

by pyth01 hours ago|

parent|

[-]

This is literally the point of stacked PRs. You implement the refactor in branch A, then branch B is created on top of that so you can implement your feature. Then you make separate PRs, one for merging branch A into main, and another for merging branch B into A. The GitHub feature just provides a nicer UX when interacting with such PRs by clearly showing dependency and allowing you to merge a stack together.