Hacker News Reader

Comment by OJFord | Hacker News Reader

The way this is explained is like it hasn't occurred to them that 'create a branch' doesn't have to mean '...off master' - I continue working with a new branch that depends on the old thing that's in a PR still simply by basing it on top - but if this comes from Google and Meta and is popular, obviously that's not the case.

My guess is that it's more about somehow seeing a more 'contextual' (not semantic exactly) diff in the second PR? So rather than including all of PR 1's changes that it's based on, just showing the actual diffs in the commits in isolation, or as if rebased (only PR 2's intended patch set, not the master fork point through tip of PR 1) on master?

Though I haven't read further than I can as a non-subscriber, perhaps it would be clearer when it explains how they're doing it on GitHub (the above would require some rebasing or target branch and further PR automation).

View on HN

The problem is that if you rebase branch1 based on feedback, your branch2 now has a dangling source commit. So you need rebase-fu to fix, and it’s per-stacked-branch. Even with rerere the merges can be annoying.

The tooling in Phab (and Graphite) makes stacks much easier to work with by auto-rebasing the whole stack as you push new changes to base commits.

> So you need rebase-fu to fix, and it’s per-stacked-branch.

Note that `git rebase --update-refs` lets you just rebase the last branch and the entire stack gets updated. You just need to know which branches to forcepush.

Ah ok, fair enough. I can certainly appreciate that would be helpful, because yeah the 'annoying rebase-fu' is how I do that.

TFA seems to get hung up on reviewing individual commits instead of a set of them ('a diff is basically a commit' - err well yes) when actually the benefit per my guesswork and your description is more about the automation, and there's no inherent reason (as far as we've discussed anyway) that it couldn't be doing that with a set of multiple commits anyway.

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?

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'.)

Reply on news.ycombinator.com