AST-native version control · v0.01
Weave keeps your code as a syntax tree in a SQLite database instead of as lines in files. Commits, branches, and merges operate on the tree, so edits to different parts of a file don't conflict the way they do in git.
How it differs from git
In git
Git treats a source file as a sequence of lines of text. When two branches change the same file — even in different functions — git compares line ranges and reports a conflict when those ranges overlap or sit adjacent. It works on line positions, not on the structure of the code.
With several coding agents working in one repo at once, this comes up often. They produce large, overlapping edits, and much of the time goes into resolving conflicts that aren't actual disagreements about the code.
In Weave
Weave parses your code into an abstract syntax tree and stores it in SQLite, where every node has a stable id. A change is a structural operation on a node — replace an expression, insert a function, delete a branch — rather than a text diff.
Two edits conflict only if they touch the same node. Different functions are different nodes, so they merge automatically, and adjacent lines or formatting don't cause conflicts. When there is a real conflict, it's scoped to the single node both sides changed.
How it works
Everything in Weave is an append-only log of structural ops. Any version of your code is just those ops replayed onto a tree.
Your source is parsed into AST nodes with stable ids and stored in a WAL-mode database. Nothing lives on disk as text — even running the program renders the tree in memory.
A commit is a set of structural operations —
replace, insert_after, append_child,
delete — each targeting a node id. State is materialized by replaying the
op chain.
Each agent gets its own worktree forked from main. It reads, edits, and
runs code entirely inside the database — no checkout, no working directory to dirty.
Ops touching nodes untouched on main replay cleanly. Only a same-node
collision returns a conflict — a tiny base/main/worktree report scoped to
one node, small enough to hand to an LLM that writes code combining both intents.
Merge queue
Structural merging avoids conflicts in the code. A merge queue avoids conflicts in CI: agents
can commit to main concurrently, and main only advances through revisions that
pass the test suite.
Verification runs outside the lock
Conventional CI serializes: each commit locks main, runs the whole suite, then unlocks —
so ten agents mean ten suites back to back. Weave's commit_to_main is a
speculative queue (bors / GitHub-merge-queue style). Enqueuing takes a
millisecond write-lock — enough to run conflict checks and assign node ids — then releases.
Verification then runs concurrently, against the predicted landing state: the
current head, plus every transaction queued ahead of you, plus your own ops.
Main only advances through green states
Landing is a hash check. If the state you verified is byte-identical to the real landing state, it lands immediately with no re-run. If a commit ahead of you was evicted, your hash no longer matches and you re-verify against the corrected state. Main advances only through verified states, in ticket order, so every revision on main passes the suite. A failing commit is evicted and returned to its author; the commits behind it re-check and continue.
*Each test's pass is cached against the content hash of its dependency closure. A test re-runs
only when code it can actually observe changed, so the landing gate is usually nearly free.
Figures measured in test_speculative.py.
Demo
Conflict size
When two edits do touch the same node, Weave reports just that node — the base, main, and worktree versions — instead of a file full of conflict markers. That's small enough to hand to an LLM to resolve, and edits to different nodes don't conflict in the first place.
Comparison
You still branch, commit, and merge. Here's where Weave overlaps with tools you already use, and where it differs.
FAQ
Conceptually, no — Weave keeps the branch/commit/merge model you already think in. Under the hood it replaces text storage with a syntax-tree database, so the everyday operations map over directly. It's a different engine, not a different mental model.
When two worktrees change the same node, Weave returns a per-node conflict
report with the base, main, and worktree versions of
just that node. Because the scope is one expression rather than a whole file, it's small
enough to resolve automatically — the merge agent writes code that combines both sides'
intent via resolve_merge.
Through a dependency-free MCP stdio server exposing the store as tools —
create_worktree, read_source, commit,
run_program, merge_worktree, resolve_merge, and more.
Agents run with filesystem and shell access disabled: the code never exists as a file for
them to touch.
No. The tree lives in SQLite, and even running the program renders the projection in-memory — so “run the code” never materializes a file. The database is the single source of truth.
The reference implementation demos Python via its AST, but the architecture is language-agnostic: anything with a parser to build the tree and a renderer to project it back to source can ride the same op-log and merge engine.
Not yet — Weave is v0.01, a working research prototype exploring what version control looks like when the store is a syntax tree. It runs the full loop today: parallel agents, node-level auto-merge, and LLM-resolved conflicts. Treat it as a demo of the idea, not a drop-in for your team repo.