Three unrelated-looking Git projects trended together this week, and they turn out to be the same story told at three scales. worktrunk is a command-line tool for juggling Git worktrees. OmniDiff is a new difftool. And Pando is a Git backend OpenAI rebuilt from scratch. What connects them is that coding agents make far more branches, commits, pushes and diffs than human teams do, and the tooling around Git was never designed for that volume. This week the tooling started catching up.
The problem agents create
Git itself is fine. What breaks is the ergonomics layer around it. When you run
one agent on a repo, you work the way you always did: a branch, some commits, a
diff to review. When you run two or three agents at once — one refactoring a
component, one writing tests, one chasing a bug — each needs its own working copy
of the repo so they don't trip over each other's edits. Git already solves that
with worktrees: separate checked-out directories backed by one .git. The
trouble is that worktrees are clumsy to drive by hand, and the moment you have
several live at once, the bookkeeping eats the time the parallelism was supposed
to save.
That is the exact seam the first tool targets.
worktrunk: worktrees as easy as branches
worktrunk describes itself as a CLI for
Git worktree management "designed for parallel AI agent workflows." Its pitch is
small and concrete: with plain Git, even starting one worktree makes you type the
branch name three times — create it, change into its directory, and clean it up
later. worktrunk collapses that into single commands. You address a worktree by
its branch name, and it computes the directory path for you from a template.
wt switch, wt list, wt remove, and a wt merge that handles squash, rebase,
merge and cleanup in one step.
A few of its features are built squarely for the agent case. It can generate
commit messages from diffs, which matters when a machine is producing dozens of
small commits you would otherwise have to summarize yourself. Its interactive
picker shows CI status and a diff, log or PR preview per branch, so you can see at
a glance which agent's worktree is green. And it shares build caches across
worktrees using copy-on-write, so a fresh worktree can reuse node_modules or a
target directory without rebuilding or copying it — on APFS, btrfs and XFS. For
a frontend developer, that last one is the difference between spinning up a new
agent in seconds and waiting for npm install every single time.
The repo has drawn attention fast: roughly 12.2k stars, 474 forks and 5,526 commits as of today. Its stated goal is to make "git worktrees as easy as branches," and the reason that goal suddenly matters is agents.
OmniDiff: diffs built for reviewing a machine's edits
The second project attacks a different part of the loop. When an agent hands you a change, you review a diff — and the line-oriented diff Git has shown since the beginning is a poor lens for that. It marks whole lines as changed even when one token moved, and it gives up entirely on anything that isn't plain text.
OmniDiff calls itself "fast, robust, accurate content-aware diffing." Instead of comparing lines, it detects the file type and uses tree-sitter grammars — it ships them for 26 languages — to compare code by structure. It reports that 98.8% of changes are diffed with content-specific algorithms rather than a line-by-line fallback. The practical effect is that it highlights only the parts of a line that actually changed and can show moved code as moved, which is exactly the signal you want when you are auditing an edit you didn't write.
It is also quick, which matters if you drop it into git difftool and call it on
every review. Over 2,302 benchmark fixtures on a laptop, the README reports a
median of 4.4 ms, a p90 of 35.7 ms, and a p99 of 181 ms.
A separate robustness run over 442,530 code file pairs completed 99.95% of them
successfully. It is honest about where it still falls short: against hand-labeled
ground truth, 59.0% of cases had zero mismatched bytes in its fuller mode and
69.0% in its minimal mode, and the project says plainly that its accuracy targets
are not yet met. That candor is worth noting — it is young, and you should treat
it as such.
Pando: the same curve, at OpenAI's scale
The third project is the far end of this curve. In "Scaling Git at OpenAI," the company described Pando, a Git backend it rebuilt because Codex-driven commit volume had overwhelmed the system serving its internal monorepo. The telling detail is that engineers and agents still use the standard Git client and protocol — the change is underneath, in the hosting layer, invisible to the people pushing code. You do not need a monorepo to take the lesson from it: when agents are the ones generating commits, throughput you never had to think about becomes the thing that falls over first.
What this means if you build with AI
Put the three together and the shape is clear. The bottleneck in agent-assisted development is quietly moving off the model and onto the plumbing around it. Spinning up isolated workspaces, reviewing machine-generated diffs, and absorbing a higher commit rate are not model problems — they are Git-workflow problems, and for a year the workflow tools lagged the models. This week is the lag starting to close.
Amar's take
This is my read, not a benchmark: the interesting thing here is where the friction went. A year ago the hard part of using an AI coding tool was getting a good change out of it. That part works now. The part that still costs me time is everything around the change — keeping two agents from stepping on each other, and actually reading what they produced closely enough to trust it. So I'm more interested in worktrunk and OmniDiff than in another model release, because they fix the parts of my day the model can't. I'd be cautious adopting either as a hard dependency yet — OmniDiff says its own accuracy isn't there, and both are new — but I'd run them on a side branch today. The deeper point is the one Pando makes without meaning to: as more of your commits come from agents, the tools you treated as fixed background — your difftool, your worktree juggling, your Git host — become the things you have to think about again. Worth watching which of these is still around in six months.
