Who Changed What: Source Control for Multi-Agent Repos
Three agents walk into a repo. Claude Code opens a PR refactoring the auth module. Codex CLI, running in the next terminal, rewrites the same router file to add a new endpoint. Cursor, in another window, deletes the test file that both of them depend on. All three commit. Two of three merge cleanly. The build breaks at 2 AM and nobody â human or machine â can explain which agent did what, or why.
đ Read the full version with charts and embedded sources on AgentConn â
This isn't a hypothetical. The AgenticFlict dataset, published at ACM AIware '26, analyzed 142,000+ agent-authored pull requests across 59,000+ repositories and found a 27.67% merge conflict rate â with 336,000+ fine-grained conflict regions. Cross-agent pairs (Claude Code touching the same repo as Codex) conflict at 41.7%, more than double the 19.8% rate when the same agent runs parallel tasks. The multi-agent repo isn't an edge case anymore. It's the default configuration for any team running more than one coding tool, and git was never designed for it.
That's why Atlas â a desktop app that bills itself as "source control for agents" â hit 8,100 stars on GitHub this week, gaining 490 new stars per day. It's not alone. Oak launched a git alternative built from scratch for agents, hitting the Hacker News front page with 216 points and 189 comments. Diversion is pitching a scalable VCS designed for thousands of concurrent agent branches. Three independent bets, all shipping in 2026, all answering the same question: what happens to version control when most commits come from machines?
The Problem: Git Assumed One Driver Per Seat
Git's mental model is a human developer switching branches, staging changes, writing commit messages, and resolving conflicts by reading diffs. Every one of those assumptions breaks when agents are the committers.
No awareness of parallel work. Each agent starts from a frozen snapshot and has no visibility into what other agents are building. Two agents can spend 20 minutes writing overlapping changes to the same file, and neither knows until merge time. The Daniel Vaughan analysis of 33,596 agent-authored PRs breaks down where it hurts most: 57.6% content conflicts (overlapping line edits), 26.8% modify/delete conflicts (one agent refactored what another deleted), and 15.1% add/add conflicts (both agents independently created the same file).
Read the full AgenticFlict analysis â
No provenance trail. Git records who committed and what changed, but not why or how the decision was made. When a human commits, the reasoning lives in their head and in the PR description. When an agent commits, the reasoning lived in a prompt and a chain of tool calls that vanished when the session ended. Six months later, someone reads refactor: simplify auth flow and has no way to know whether that was a human's architectural judgment or an agent hallucinating a simpler approach â the problem we've covered as comprehension debt.
No coordination primitive. Git gives you branches for isolation and merges for integration. It doesn't give you a way to tell Agent B "don't touch src/routes/ because Agent A is rewriting it right now." The coordination has to happen above git â in the orchestrator, in the task decomposition, in the file-boundary scoping. As Autonoma's analysis found, the 42% structural conflict rate drops to near-zero when agents simply can't touch the same files. The fix isn't in the VCS. It's in the instructions.
â ī¸ Contrarian corner: The VCS layer might be a distraction. The 41.7% cross-agent conflict rate doesn't mean git is broken â it means prompts are broken. If you scope each agent's task to non-overlapping files (via AGENTS.md manifests, directory-level ownership, or an orchestrator that assigns file locks), merge conflicts functionally disappear. The real investment should be in task decomposition, not version control migration.
Hugging Face CEO Clement Delangue captured the underlying tension in a post that resonated across the developer community:
That's a fair argument â and it's the argument you'll hear from teams that run multi-agent setups today using nothing more than git worktrees and discipline. But it breaks down at scale. When you have 5 agents running overnight maintenance â vulnerability remediation, dependency updates, test generation, documentation â scoping non-overlapping files becomes its own coordination problem. Someone has to know the full dependency graph to avoid semantic conflicts that merge cleanly but break behavior. That "someone" is increasingly a tool, not a person.
The Landscape: Extend Git or Replace It
The market is splitting into two camps, and understanding which one you're buying into matters more than which specific tool you pick.
Camp 1: Extend Git â Atlas and the Checkpoint Model
Atlas from pacifio is a Tauri desktop app built in Rust and TypeScript that treats git as the storage layer but adds an agent-native control plane on top. The core primitive is the checkpoint: every agent run produces a commit that's linked back to the session that created it, including the original prompt, every tool call, and the agent's reasoning chain. All of it stored locally in .atlas/sessions.db, with secrets scrubbed before anything touches disk.
This solves the provenance problem directly. When you're debugging a breaking change six weeks later, you don't just see refactor: simplify auth flow â you see the prompt that triggered it, the files the agent read before making its decision, and the intermediate states it considered. Session links survive rebases and amends through patch-id reconciliation.
But Atlas does more than checkpointing. It runs Claude Code, Codex, and any agent in the ACP registry (Cursor, OpenCode, Kilo Code, and more) side-by-side in tabs, with a shared semantic memory index that all agents can query. This means Agent B can ask "what did Agent A change in the auth module?" before touching the same files. The @ mention system lets agents reference files, folders, symbols, branches, commits, notes, and past sessions â a context layer that git never provided.
The technical architecture: Vue/React frontend on CodeMirror, Rust backend via Tauri, SQLite for session storage, Bun as the package manager. Apache-2.0 licensed. The 8,100 stars and 490/day growth rate put it in the top tier of developer tools trending on GitHub â and our GitHub digest confirms it's part of a broader pattern where 5 of the top 8 trending repos are agent-adjacent infrastructure.
View the analysis on Alook â
The Augment Code guide to multi-agent workspaces recommends a similar architecture: Conductor enables 3â8 parallel agents on the same repo, each in its own git worktree, with a visual dashboard for monitoring. VS Code positioned itself as "your home for multi-agent development" where Claude and Codex agents run alongside GitHub Copilot. The pattern is converging: git as the base layer, worktrees for isolation, a coordination app for visibility.
Camp 2: Replace Git â Oak and Diversion
Oak takes the radical position that git itself is the bottleneck. Built in Rust around BLAKE3 hashing and content-defined chunking, Oak redesigns version control around one insight: the unit of work for an agent is a session, not a commit.
The performance numbers back the thesis. Oak's published benchmarks show snapshots in many-small-files repos dropping from 29,723ms on git to 1,412ms on Oak (95% faster). Task snapshots of large binaries go from 443ms to 23.2ms (also 95%). Full diffs over multi-GB binaries from 3,945ms to 271ms (93%). These aren't synthetic benchmarks â they're the exact operations agents hit dozens of times per task when checkpointing, branching, and diffing.
Oak's design addresses three git pain points for agents specifically:
-
No lock contention. Git's shared
.git/index.lockcorrupts when two parallel agents touch the same repo. Oak eliminates the shared lock. - Lazy mounting. Cloning a repo in Oak streams the manifest first, then fetches file contents on first read â agents start editing within a second instead of waiting for a full clone.
- Machine-readable output. Git's status output is designed for human eyes. Oak's API returns structured data that agents can parse without regex hacks.
The broader "git for agents" thesis has generated sustained Hacker News debate â a separate Show HN thread on the same topic drew additional community engagement:
The Hacker News reception was mixed but substantive. The top criticism: agents already know git from training data, so introducing a new VCS means agents have to learn unfamiliar tooling. The creator's response: Oak isn't about syntax familiarity but optimizing runtime workflows â parallel sandboxing, large repos, non-interactive execution, and token efficiency. Oak is at v0.99.0 public beta, Apache-2.0, with no Windows build yet and an export command that replays branches into standard git history for compatibility.
Diversion takes a different approach: a centralized VCS (not distributed like git) designed for massive repositories and thousands of concurrent branches. Already recommended by Epic for Unreal Engine workflows, Diversion's pitch is partial clones (only the paths you need from a 50M-file repo), native large-file support without LFS, and prompt provenance metadata baked into the commit model.
Read the Diversion blog post â
âšī¸ The numbers that matter: AgenticFlict found content conflicts at 57.6%, modify/delete at 26.8%, and add/add at 15.1%. The cross-agent conflict rate (41.7%) is more than double the intra-agent rate (19.8%). This means mixing agent vendors on the same repo is measurably riskier than running one agent type â a finding that should inform your multi-agent strategy.
The Git Worktree Baseline: What Works Today
Before evaluating new tools, there's a zero-cost baseline that every multi-agent team should already be running: git worktrees.
Claude Code shipped worktree support in v2.1.49 (February 2026). Run claude --worktree <name> and you get an isolated session on its own branch under .claude/worktrees/, so you can build a feature in one terminal while fixing a bug in another. The VS Code blog describes VS Code as "your home for multi-agent development" where Claude and Codex agents run alongside GitHub Copilot â each in its own worktree.
The Developers Digest playbook puts it simply: worktrees convert silent runtime file corruption into visible merge-time conflicts. That's not a perfect solution â you still get conflicts â but at least you know about them, and you know which agent's branch caused them.
The practical workflow:
- One worktree per agent session, one branch per task
- Each agent gets a file-boundary scope via its instruction file (CLAUDE.md, AGENTS.md, or project-level rules)
- Merge sequentially, not concurrently â the agent that finishes first merges first
- Run
git merge-treein pre-merge hooks for early conflict detection - Review agent PRs with the same rigor as human PRs â the 10x PRs, 1x reviewers bottleneck is real
This is the setup that most production teams are running today, and it works. The question Atlas, Oak, and Diversion are answering is: what's missing from this baseline?
What's Missing: The Provenance Gap
The answer is provenance â knowing not just what changed, but why, how, and by which agent's reasoning process.
Git blame shows you which commit touched a line. It doesn't show you the prompt that triggered the change, the files the agent read before deciding to make the change, the alternative approaches the agent considered and rejected, or whether the change was the agent's own initiative or a response to a human instruction.
Atlas's checkpoint model addresses this directly. Oak's session-as-unit-of-work design encodes it into the VCS primitive itself. And the Entire.io analysis predicts that provenance metadata will become standard: future version control needs to capture prompt provenance, decisions, reasoning traces, implementation context, and metadata.
This isn't academic. When your fleet of agents is producing the majority of commits â Stripe already merges 1,000+ agent-authored PRs per week â you need a way to audit the reasoning behind those commits at scale. The Hacker News community keeps returning to this problem:
The teams building Atlas and Oak are betting that git's commit message field isn't enough.
What This Means for You
đĄ The three-move playbook:
1. Today: Adopt git worktrees as baseline isolation for every agent session. This is free and immediate.
2. This quarter: Evaluate Atlas if you need checkpoint provenance and session tracking across multiple agent types. At 8.1k stars and growing 490/day, the community is large enough that you won't be alone.
3. Watch, don't migrate: Oak and Diversion are solving real problems but lack ecosystem maturity. Monitor their adoption curves â when your CI provider and code review tool support them natively, that's the migration signal.
The version control layer is becoming agent infrastructure. Git will remain the foundation for most teams through 2027, but the coordination layer on top of it â checkpoints, shared memory, session tracking, conflict prediction â is where the real competition is happening. Atlas's 8,100 stars aren't about a better git GUI. They're a demand signal that operators are tired of debugging agent commits with git blame and a prayer.
The question for every team running multiple coding agents: can you tell, right now, which agent changed what, and why? If you can't, the next merge conflict at 2 AM is going to hurt worse than the last one.
Originally published at AgentConn
