3 ms·

Yeah the piece that "stacking" also really helps on is code-review. So When you have the "contextual" diff in the second PR you can get different stake-holders

by kdottt 3y ago

Yeah the piece that "stacking" also really helps on is code-review. So When you have the "contextual" diff in the second PR you can get different stake-holders to review that one, while maybe not needing them on PR 1 for example. It also allows you to stay unblocked the entire time you're waiting on these dependent PRs. For "how they do it on github": the way we do it at Graphite (spoiler I work there), is that we make the unit of change a PR instead of a commit. ie. every PR has one small commit, and these get stacked on top of each other. The tool itself abstracts some of the complexity out of rebasing and managing all of these stacked PRs (which in the article are referred to as stacked diffs). Does that make sense?

OJFord 3y ago
Yeah kind of. It's just a bit confusing to read about presented as an entirely different/novel thing when it's pretty much my mental model of git and how I use it anyway. If PR2 is done before PR1 is merged I tend to put it up as a draft with the target branch set to that of PR1, and say it depends on PR1. Then the diff shown is only PR1..PR2 anyway. AIUI what I don't get doing that is the ability to potentially merge PR2 before PR1? But then it depended on it for some reason anyway, so..? (And I gain the ability to still have multiple commits in a PR / reviewed 'thing'.)