weave: Semantic Git Merging for the Multi-Agent Era

When two developers edit different functions in the same file, Git's line-based merge algorithm sees overlapping changes and throws a conflict, even though the actual code doesn't overlap. This problem has gotten worse as AI coding agents enter the workflow. Tools like Copilot, Cursor, and Claude Code edit files directly, and if two agents touch the same file, you're back to manual merge resolution.

weave is a new tool that attempts to solve this with semantic awareness. Instead of treating files as sequences of lines, it parses code into an abstract syntax tree using tree-sitter and merges at the entity level: functions, classes, methods, and other named constructs.

The core claim is simple: if two edits modify different entities in the same file, there's no conflict. Git doesn't know this. weave does.

What's Actually New

The concept isn't new. Academic research on AST-based merging goes back decades, and tools like semanticmerge and git-imerge have explored alternatives to line-level merging. What's different here is the practical packaging:

1. Tree-sitter integration: Using tree-sitter's incremental parsing makes this fast enough for real-world use. The parser is already embedded in editors like Neovim, Helix, and Zed, so the dependency is lightweight.

2. Multi-agent coordination layer: This is the genuinely novel part. weave includes a CRDT-based state coordination system where agents can claim entities before editing. The idea is to prevent conflicts rather than just resolving them. An agent announces "I'm editing function X" and other agents know to avoid it or coordinate.

3. MCP server: A Model Context Protocol server exposes 15 tools that AI agents can call directly. This means Claude, GPT, or other LLMs can use weave's entity extraction and coordination capabilities programmatically.

4. 28 language support: Through tree-sitter grammars, weave handles TypeScript, Python, Go, Rust, Java, C, C++, Ruby, PHP, Swift, Kotlin, and more. Also supports JSON, YAML, TOML, CSV, and Markdown.

The Numbers

weave claims to have tested 31 merge scenarios across 7 languages:

• weave: 31/31 (100%)
• mergiraf: 26/31 (83%)
• git: 15/31 (48%)

They also report 83 "real-world wins" with 0 regressions across 4,917 file merges. The tool has around 1,500 downloads.

These numbers look impressive, but they come with caveats. The 31-scenario test suite is likely curated to highlight weave's strengths. Real-world merge conflicts include complex refactoring, renames across files, moved code, and semantic changes that break interfaces. No merge tool handles all of these. The 4,917 file merges on real repositories is more convincing, but without seeing the test methodology or having independent reproduction, treat the 100% claim skeptically.

Three-Layer Architecture

weave offers three tiers of functionality:

Layer 1: Merge Driver This replaces git's default merge strategy. When you run git merge, weave parses both sides and the base, identifies entities, and merges them independently. If function A was modified on both sides identically, it's a conflict. If function A was modified on one side and function B on the other, both changes apply cleanly.

Layer 2: CRDT Coordination For multi-agent workflows, this layer lets agents claim ownership of entities before editing. Using CRDTs (conflict-free replicated data types), the state stays consistent without central coordination. Agents can detect potential conflicts before they happen.

Layer 3: MCP Server The Model Context Protocol server exposes entity extraction, conflict detection, and coordination tools. An LLM can ask weave to parse a file, identify functions, check for conflicts, or claim entities.

What This Actually Solves

The real value is narrow but genuine: when two agents (or developers) edit different parts of the same file, line-level merging produces false conflicts. This happens constantly in agent workflows because agents tend to edit the same popular files (configuration, main entry points, shared utilities).

The coordination layer is more speculative. CRDT-based entity claiming sounds useful in theory, but multi-agent coordination is an unsolved problem in practice. Agents don't reliably communicate state, and adding coordination overhead can slow down workflows. The MCP integration is well-intentioned but adds complexity.

Limitations and Concerns

Early stage: 1,500 downloads is a small user base. Edge cases in merge behavior won't surface until more people use this on diverse codebases.

Tree-sitter coverage: Not all languages have mature tree-sitter grammars. Support for newer languages or domain-specific languages may be incomplete.

Semantic conflicts: weave handles syntactic conflicts (different functions) but not semantic ones. If function A calls function B and both change signatures, weave won't catch the breaking change.

Performance overhead: Parsing entire files into ASTs for every merge adds time. For large files or monorepos, this could matter.

Adoption friction: Changing merge drivers requires team buy-in. If only one person uses weave, coordination benefits disappear.

Who Should Try This

If you're running multiple AI agents on the same codebase, weave addresses a real pain point. The merge driver alone is useful for reducing false conflicts. The coordination and MCP layers are more experimental but worth exploring if you're building multi-agent systems.

For individual developers with traditional workflows, the benefit is smaller. Git's line-based merging works fine for most scenarios, and the added complexity of AST-based merging may not justify the gains.

The project is available via brew install weave and the GitHub repository. The setup is straightforward: weave setup configures the merge driver for your repository.

Bottom Line

weave is a well-engineered solution to a specific problem: false merge conflicts from line-level algorithms when edits don't actually overlap. The tree-sitter integration is solid, the multi-agent coordination is interesting but unproven, and the MCP server is forward-looking. The 100% success rate claims should be taken with salt, but the underlying approach is sound. If your workflow involves multiple agents editing shared files, this is worth evaluating.