Weave – A language aware merge algorithm based on entities

Some context on the validation so far: Elijah Newren, who wrote git's merge-ort (the default merge strategy), reviewed weave and said language-aware content merging is the right approach, that he's been asked about it enough times to be certain there's demand, and that our fallback-to-line-level strategy for unsupported languages is "a very reasonable way to tackle the problem." Taylor Blau from the Git team said he's "really impressed" and connected us with Elijah. The creator of libgit2 starred the repo. Martin von Zweigbergk (creator of jj) has also been excited about the direction. We are also working with GitButler team to integrate it as a research feature.

The part that's been keeping me up at night: this becomes critical infrastructure for multi-agent coding. When multiple agents write code in parallel (Cursor, Claude Code, Codex all ship this now), they create worktrees for isolation. But when those branches merge back, git's line-level merge breaks on cases where two agents added different functions to the same file. weave resolves these cleanly because it knows they're separate entities. 31/31 vs git's 15/31 on our benchmark.

Weave also ships as an MCP server with 14 tools, so agents can claim entities before editing, check who's touching what, and detect conflicts before they happen.

At this point, the question is: why keep files as blobs in the first place. If a revision control system stores AST trees instead, all the work is AST-level. One can run SQL-level queries then to see what is changing where. Like

  - do any concurrent branches touch this function?
  - what new uses did this function accrete recently?
  - did we create any actual merge conflicts?

It is quite early stage, but the surprising finding is: instead of being a depository of source code blobs, an SCM can be the hub of all activities. Beagle's architecture is extremely open in the assumption that a lot of things can be built on top of it. Essentially, it is a key-value db, keys are URIs and values are BASON (binary mergeable JSON) [2] Can't be more open than that.

[1]: https://github.com/gritzko/librdx/tree/master/be

[2]: https://github.com/gritzko/librdx/blob/master/be/STORE.md

The merge conflict is the symptom. The root problem is parallel agents have no coordination primitives before edits happen. The MCP server angle is the more interesting long-term bet here because it moves conflict avoidance earlier in the workflow rather than cleaning up damage after the merge. Entity claiming as a first-class primitive is where this gets really interesting for multi-agent coding. What do you think?

How does it compare to https://mergiraf.org/ ? I've had good experience with it so far, although I rarely even need it.

It's also based on treesitter, but probably otherwise a more baseline algorithm. I wonder if that "entity-awareness" actually then brings something to the table in addition to the AST.

edit: man, I tried searching this thread for mention of the tool for a few times, but apparently its name is not mergigraf

Interesting that Weave tries to solve Mergiref's shortcomings (also Tree-sitter based):

> git merges lines. mergiraf merges tree nodes. weave merges entities. [1]

I've been using mergiraf for ~6 months and tried to use it to resolve a conflict from multiple Claude instances editing a large bash script. Sadly neither support bash out of the box, which makes me suspect that classic merge is better in this/some cases...

Will try adding the bash grammar to mergiraf or weave next time

[1] https://ataraxy-labs.github.io/weave/

If both sides refactor the same function into multiple smaller ones (extract method) or rename it, can Weave detect that as a structural refactor, or does it become “delete + add”? Any heuristics beyond name matching?

Saw this on Twitter a few weeks ago, interesting approach.

The post links to the GitHub repo, but imo the website does a better job of explaining what it does: https://ataraxy-labs.github.io/weave/

So Weave claims AI based development increase git conflict frequency.

Given that most git conflicts are easy to solve by person who didn't involved at changes, even for a person who don't know that programming language, it's natural to let AI handle the git conflicts.

Solving a git conflict is most often a simple text manipulation without needing much of context. I see no problem current AI models can't do it.

I tried this with the kind of merge conflict I'd expect it to solve automatically, and it didn't. Is it supposed to work while rebasing, or is it strictly for merges?

Website: https://ataraxy-labs.github.io/weave/

I haven't tried it but this sounds like it would be really valuable to me.

It's still possible for two commits to conflict only semantically, one obsoleting the other. Merging both would lead to dead code so perhaps stricter (line-base or ast-based) conflicts would be preferable.

Awesome, I've been wanting this for a long time! Any chance of Swift being supported?

How can this be used with jj?

It’s described as a “merge driver for Git”. Is it usable independently of git? Can I use it to diff arbitrary files?

Very cool, would love to see Ruby support added.

The entity-level approach is a meaningful step up from line-based merging. Anyone who has dealt with a merge conflict where git splits a function signature across conflict markers knows how much context is lost at the line level. Curious how this handles languages with significant whitespace like Python, where indentation changes can shift the semantic meaning of entire blocks.

No C#?

> This happens constantly when multiple AI agents work on the same codebase

What?

Is the idea of "multiple agents" of flesh and blood writing code that far fetched now?

Are agents any good with it?

Dude, I tried this for a huge merge conflict and was able to auto resolve so much and came across sem for giving my agents context on what changed for reviewing some code and surprisingly, I feel git is done for good. Much less tokens, and much more accurate, I can see something big out of this, things like weave come once in a century

Wow, I read your company description and I can confirm that we are competitors in the fiercest, most direct sense. We're both want to create the dev platform of the future, but our philosophies could not be any more polar opposite.

I hate AI. I fucking hate it. It doesn't help that the people who are infatuated with it keep shitting on me endlessly. 100,000 people scream that I'm obsolete, I'm replaceable, that I'm effectively worthless without an AI by my side, without that big ol condom stretched over my brain.

So out of spite, perhaps, I give my blood sweat and tears to my work and what I build I build for others who care so much it hurts and who live their struggles in blood and in sweat and in tears. My wrists are in so much pain that I can barely sleep at night but I don't stop coding.

You make clear that you will fight to give AI as much advantage as it can possibly have over people. "We're done building for human hands," says your website.

I will fight with all I have to give human hands as much advantage as they can get over AI.