Author Argues Commits Should Be Unit of Code Review

Julien Danjou published a blog post titled "Twenty Years of Stacking Commits" on April 28, 2026, recounting his experience with four code review tools over twenty years. Danjou documents earlier workflows using git format-patch and git send-email, the adoption of Gerrit, and later habits on GitHub. He writes that Gerrit was built in 2008 for Android by Shawn Pearce and that its Change-Id footer let one commit map to one review thread across rebases. Danjou contrasts that model with modern large pull requests-he describes reviewers opening 1,500-line PRs, scanning, and approving a bundle rather than reviewing discrete commits. He also writes that AI agents are now pushing code faster than humans can read it, which he frames as making the unit-of-review question unavoidable.

The argument for commit-level review rests on well-understood technical affordances: small, atomic commits map to single conceptual changes, ease reasoning about diffs, and cleaner tracking through rebases when tooling preserves identifiers. Industry tooling that preserves per-commit identity (for example, Change-Id in Gerrit) enables separate discussion threads and selective approvals, which reduces cognitive load compared with monolithic PRs.

For practitioners, the post highlights a recurring tension between ergonomics and onboarding: Gerrit-style workflows offered strong conceptual correctness at the cost of UX friction; GitHub-style PRs lowered entry barriers but encouraged large, multi-concept changes. Danjou's framing that AI-driven code generation increases review velocity is an industry observation reported in the post, not a verbatim forecast from vendors.

Look for tooling or process changes that restore per-commit traceability (Change-Id-like identifiers, better rebase tracking), review UI features that present stacked commits as first-class, and CI/agent integrations that enforce atomic review boundaries.