Hacker News Reader

Speaking from personal experience I’ve done both. The “optimal” PR experience is still more painful than stacked diffs if you’re working on a team that cares about commit quality (which everyone should IMO)

View on HN

Which is a valid argument imho, I just found the article to make too many pessimistic/optimistic assumptions based on the workflow they dislike/like.

If you care about having nice self-contained commits, what is your process for sending rough work-in-progress to colleagues, or to continuous integration?

You post PRs in a draft or WIP state and don’t request review until you are ready. This lets you leverage CI, but not take any time away from others who are doing review.

same in both cases. Either you put up a PR or a stack set with no reviewers and send that to whoever needs it. In the stack diff approach you can actually add reviewers for the “non controversial” parts that are ready for review and not add reviewers to the ones that aren’t ready yet.

In both cases you can rewrite your commit stack after-the-fact to add new ones, make fixes etc.

Reply on news.ycombinator.com