You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried using stacked PRs to split a change into a few logically distinct pieces to make them easier to review. But, merging them one at a time would leave main in an undesirable state. It would be really helpful to have a way to mark "only mergeable as a full stack".
Example:
PR1 (branched off of main): make more dependencies optional in pyproject.toml
PR2 (branched off of PR1): add CI coverage to ensure missing optional dependencies only lead to failures in the optional features that would actually need them.
PR3 (branched off of PR2): improve error messages in cases where optional dependencies are missing.
Is this a misuse of the stacked PRs feature? I originally thought something like this was a perfectly reasonable use-case. But, it doesn't seem to be fully supported, because PR1 could be merged by itself accidentally, once approved.
Combining all these changes into a single PR is also undesirable because this logical split is much easier to review. These changes touch many different files throughout the codebase; splitting them like this makes it clear which file changes are relevant to each logical step (feature / CI coverage / improved messaging).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
I tried using stacked PRs to split a change into a few logically distinct pieces to make them easier to review. But, merging them one at a time would leave main in an undesirable state. It would be really helpful to have a way to mark "only mergeable as a full stack".
Example:
Is this a misuse of the stacked PRs feature? I originally thought something like this was a perfectly reasonable use-case. But, it doesn't seem to be fully supported, because PR1 could be merged by itself accidentally, once approved.
Combining all these changes into a single PR is also undesirable because this logical split is much easier to review. These changes touch many different files throughout the codebase; splitting them like this makes it clear which file changes are relevant to each logical step (feature / CI coverage / improved messaging).
All reactions