Hacker News Reader

Comment by systematical | Hacker News Reader

I'm confused. The solution seems easy. I have PR #80 in review and my next task depends on it. So I branch off of #80 and just starting working on #94. If there is a holdup on #80 and I want feedback on #94 I just create a draft PR with a note about #80. When #80 gets approved then I'll merge it and merge those changes into PR #94. If it gets messy, I'll just torch #94 and use my IDEs local history and do it manually.

What exactly do stacked changes do?

View on HN

Right but your diff for #94 will include all of the changes in #80 as well, because it's being compared to the main branch. When you do this a few layers up your diff is suddenly massive and hard to navigate for review.

Also if you need to change anything about #80 you have to rebase #94. Which also means the same for any other branches that you or someone else created on top of #94 that depended on #80 landing

Make feature branch off main, push, make a PR, checkout main again, make a different feature branch with a different PR, repeat. Why would I continue using the other feature branch for the 2nd?

Because if the second feature requires the code changes from the first PR you can't do that...

If your team doesn't have a use for stacked diffs that's fine. Teams of one also don't use pull requests and might not understand why we need those.

It's very rarely come up for me that multiple open issues depend on each other. Maybe it happens more in some codebases than others.

Reply on news.ycombinator.com