6 ms·
Not entirely sure why a new term and why merge those local 'diffs' to your local 'main' at all? Open PR A-->main, while it's getting reviewed (or maybe it's in
by aldanor 3y ago
Not entirely sure why a new term and why merge those local 'diffs' to your local 'main' at all?
Open PR A-->main, while it's getting reviewed (or maybe it's in WIP state for some reason), create a branch B off A, and eventually open PR B-->A. Now, you never actually merge B-->A, it's only there so that the PR can be reviewed and diff can be seen. Can be repeated as needed.
In fact, IIRC, in the example above, if you merge PR A, GitHub will switch PR B's target branch to whatever A was merged to (in this case, main).
- ppwwyyxx 3y agoThe workflow you described is very hard to use in practice, for example: 1. If you edit A after reviewer comments, B will now have a dangling source. You'll need some rebase-fu to handle that, and the pain is significant if the chain is long. In stacked-diff workflow, it is handled automatically. 2. If you need to insert a new PR between A and B, or swap the order of some PRs in the chain, you'll need to manually do a lot of rebase-fu, and possibly manually updating the "target branch" on github. While in a stacked-diff workflow, all of these are handled automatically.
- Liskni_si 3y agoRe > 1. … You'll need some rebase-fu to handle that, and the pain is significant if the chain is long. `git rebase --update-refs` on the last branch will handle updating of all the intermediate branches in the stack, you just need to force-push them all at the end. It does help with 2. as well, but you will indeed need to manually update the target branch of a single PR on GitHub.