The commit is becoming the wrong-sized receipt.
Pablo Santos Luaces argues that version control is entering its biggest period of experimentation since 2005, pushed by agent-driven commit volume and renewed work on forges, storage, stacked changes, provenance, and huge repositories.[1] He also discloses deep commercial and advisory ties to several projects he discusses. Read it as an informed, interested map of the territory—not a neutral census.
The useful signal is not “Git is dead.” It is that a commit hash, author line, and message were sized for a person making a bounded change. A scheduled agent can arrive from a prompt, attach a workspace, message another session, write through tools, and hand off a result. Compressing that chain into fix stuff is not version control. It is evidence disposal.
More change velocity does not need a bigger speedometer. It needs suspension.
The editor is already generating change pressure.
VS Code 1.137 introduced preview Automations that can run recurring agent tasks hourly, daily, weekly, or on demand. The same release documents queued agent messages, workspace attachment with an isolated-worktree option, and an agent host that can connect multiple windows to one session.[2] Those are product capabilities and preview boundaries, not proof that every team should switch them on.
But they make the systems question impossible to dodge: when work can start on a clock and continue across sessions, the durable object cannot be only the final patch. The trigger, request, baseline, workspace, actor chain, tool boundary, checks, and landing decision belong in the service record.
Operation history is a better clue than commit theater.
Jujutsu’s documentation describes an operation log that records each repository-modifying operation with a snapshot of repository state plus metadata including timestamps, username, hostname, and description. It supports undoing an operation, reverting a specific operation, or restoring an earlier repository state.[3] Jujutsu is not presented here as a magic agent solution. Its model is simply a sharp clue: history can record the manipulation of history itself.
That matters when an agent rebases, abandons, rewrites, resolves, or splits changes before the reviewer ever sees a pull request. The final graph can look clean while the path to it was a demolition derby. A recoverable operation trail gives the garage a black box, not just a polished hood.
Build a change packet, not a prompt museum.
Do not archive every hidden thought or dump megabytes of chat into Git. Preserve the small set of facts that lets another operator understand, reproduce, challenge, and safely continue the work:
- Identity: human owner, initiating surface, agent or automation label, model/harness revision where relevant, and start time.
- Intent: request, constraints, acceptance conditions, explicitly excluded work, and links to the issue or incident.
- Isolation: baseline revision, branch/worktree/workspace, allowed write and network boundaries, and touched paths.
- Landing: tests and review actually run, unresolved caveats, merge/reject authority, resulting revision, and rollback handle.
The Hacker News discussion around Luaces’s essay ranges from excitement about provenance and new VCS models to skepticism about the premise and the predicted fall of distributed workflows.[4] Good. The future is disputed. The change packet is useful on old Git, new Git, Jujutsu, a hosted forge, or a folder with a very nervous human standing beside it.