Hacker News Reader

Comment by dminik | Hacker News Reader

Maybe this is just a skill issue, but even with several attempts I just can't figure out why I would use stacked diffs/PRs. Though maybe that's because of the way I work?

I notice a lot of examples just vaguely mention "oh, you can have others review your previous changes while you continue working", but this one doesnt make sense to me. Often times, the first set of commits doesn't even make it to the end result. I'm working on a feature using lexical, and at this point I had to rewrite the damn thing 3 times. The time of other devs is quite valuable and I can't imagine wasting it by having them review something that doesn't even make it in.

Now, I have been in situations where I have some ready changes and I need to build something on top. But it's not something just making another branch on top + rebase once the original is merged wouldn't solve.

Is this really worth so much hype?

View on HN

We use this feature extensively at $dayjob.

Imagine you have some task you are working on, and you wish to share your progress with people in bite sized chunks that they can review one at a time, but you also don’t want to wait for their reviews before you continue working on your task.

Using a stacked set of PRs you can continue producing new work, which depends on the work you’ve already completed, without waiting for the work you’ve already completed to be merged, and without putting all your work into one large PR.

I've always done this by just creating new PRs that are based on the branch of the old one. Maybe this is a UI improvement?

Yes, you can do that, but there's lots of things about it that are awkward. This makes it a more first-class feature.

Yeah that is a “stacked” pr. The tooling is nice especially when have a larger stack and make changes to the first branch. Update refs + push all branches, same with merging and rebasing onto main.

You can review PR’s commit by commit, and you can ask people to review PR’s commit by commit. Not a big deal.

Then you lose the ability to merge the portion of work which has been agreed to, until the whole change overall has been agreed to.

in Phabricator you either abandon the original diffs entirely, or you amend them. you don't just stack more commits with meaningless messages like "WIP", "lint fix", etc. on top.

> The time of other devs is quite valuable and I can't imagine wasting it by having them review something that doesn't even make it in.

this is now what stacked diffs are for. stacked diffs doesn't mean putting up code that isn't ready. for example you are updating some library that needs an API migration, or compiler version that adds additional stricter errors. you need to touch hundreds of files around the repository to do this. rather than putting up one big diff (or PR) you stack up hundreds of them that are trivial to review on their own, they land immediately (mitigating the risk of merge conflicts as you keep going) then one final one that completes the migration.

I also branch out, and rebase. Also, keep updating and rebasing until merged. It’s tedious when PR take ages for approval, as I keep creating new branches on top of each other.

So, when I saw this announcement seemed interesting but don’t see the point of it yet.

Reply on news.ycombinator.com