Thanks for indulging me so far, by the way, I really appreciate this discussion, it's very stimulating.

Thanks for indulging me so far, by the way, I really appreciate this discussion, it's very stimulating. After thinking about the whole thing I think I can summarize my opinion a lot better now: Stacked diffs are a category error. Units of discussion, and units of integration, should not be conflated. A branch is my unit of intended integration: merge all of it or none of it. The fact that reviewers need smaller slices to discuss does not imply those slices should become independently landable history objects. That’s a UX concern for the review tool, not something I should have to encode into Git history. The ideal system would let me seed discussion however I want (by commit, by path, by subsystem, by semantic region of the diff, etc) without forcing me to pretend those are separate merge units. Github nails the "merge unit" (CI runs against the whole branch, the branch either merges or doesn't, etc), but absolutely fumbles in the discussion part. I hate that I'd have to change the merge unit just to fix their discussion UX.

Posted by ninkendo on Apr 14, 2026, 3:29 AM

Tags

• ux (Software)

Related issues

• This is the biggest problem with contracts, there's simply no way to actually say "please always execute this check".
• I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and ...
• the new VSCode UI, looks cute, i don't like it.
• I've been working on my own private harness for the past 8 months, and I've been collecting ideas from such repos I've stumbled upon.
• The way AI is able to interact with outside resources is pretty impressive, but the quality of code it produces to me is still questionab...
• Add PR-style review comments in Git Diff UI that feed into the active agent thread