Weave

Install

brew install weave

Or build from source (requires Rust). Two binaries, both required: weave (the CLI you run: setup/explain/check/...) and weave-driver (the one git itself invokes on every merge; weave setup fails without it on PATH):

git clone https://github.com/Ataraxy-Labs/weave
cd weave
cargo install --path crates/weave-cli      # the `weave` binary
cargo install --path crates/weave-driver   # the `weave-driver` binary git calls

Upgrading an existing source install? cargo install refuses to overwrite a binary it didn't put there itself, so add --force to either command above.

Setup

In any Git repo:

weave setup

This configures Git to use weave for all supported file types. Then use git merge as normal.

To revert back to normal git merging:

weave setup --off

To set up for just yourself (without modifying .gitattributes), write the same supported file type rules to .git/info/attributes instead:

weave setup --local

Quickstart

```bash weave setup # this repo now merges through weave; git merge/rebase/cherry-pick unchanged git merge <branch> # real conflicts land as markers with a refused_by: line stating why weave explain <file> # per-hunk detail for one conflicted file, read off the actual git stages

then add `*.ts merge=weave` (etc.) to ~/.config/git/attributes

```

Any MCP client, via stdio (~/.config/claude/claude_desktop_config.json etc.)

{ "mcpServers": { "weave": { "command": "weave-mcp" } } } ```

The server discovers the repo from each tool call's absolute file path, else the WEAVE_REPO env var, or its working directory. It lists six tools, one per weave command (each tool's own description states when to call it and what an empty result means):

- weave_preview: dry-run a merge of two branches, as per-file verdicts, a findings document, or the strategy weave used on each entity. - weave_edit: change code by entity, written straight to disk: replace an entity, edit text inside it, add one before or after it, delete it, or create a file. A batch is all or nothing, and an edit that breaks the parse or quietly renames an entity is refused. - weave_explain: why a file conflicted, from the merge's three stages. - weave_check: is the resolution right, plus the cross-file breakage a per-file merge driver can't see (a rename in a.py whose surviving caller lives in b.py). - weave_land: label every file of a stopped merge PROVEN, VERIFIED or REFUSED, and write the ones that pass. - weave_patch: carry an edit to a file that drifted, as a three-way entity merge.

For callers, dependencies and blast radius, use sem's MCP server. The live multi-agent CRDT tools (weave_claim_entity, weave_update_entity_content, ...) are listed only with WEAVE_EXPERIMENTAL=1. Every older tool name still answers when called, so existing clients keep working.

CLI Commands

Seven commands. Each --help line says which question the command answers, and every flag has an example (weave <command> --help).

Every earlier command name still works, with the same output. At a terminal weave prints a one-line note on stderr with the new spelling; in --json mode or when output is piped it prints nothing extra.

The weave experimental group (hidden from --help) is the live-editing prototype: it claims and releases entities and applies edits held in the .weave/state.automerge CRDT document, the same document the MCP coordination tools below use. Claims are advisory. That document lives in the repo's working tree but is never repo content: the first time weave writes it, it adds .weave/ to the repo's local .git/info/exclude (never your own .gitignore), so it never shows up in git status or gets swept into git add -A.

Weave vs Git Merge

The key difference: Git produces false conflicts on independent changes because they happen to be in the same file. Weave only conflicts on actual semantic collisions when two branches change the same entity incompatibly.

Weave vs Mergiraf

31 hand-crafted merge scenarios across 7 languages, comparable to mergiraf's own test corpus. Run weave stats --bench to reproduce:

Two of the 31 must not merge. When both sides add different decorators to the same Python or TypeScript function, decorator application is function composition, so the stack order is a semantic decision neither side made — @cache outside @auth serves cached responses without ever running the auth check. Weave refuses rather than fabricate an order, and a tool that merges those cleanly is wrong, not better. Annotations in Java, C# and Kotlin are unordered metadata, so weave still set-unions those.

All three tools correctly refuse the two decorator scenarios. Mergiraf fails on both-add-at-end-of-file and insert-between-existing; weave resolves those because it operates at entity granularity (functions, classes, methods) rather than AST node level. Full breakdown at ataraxy-labs.github.io/weave.