Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weave – A language aware merge algorithm based on entities

github.com

Post reply on HN
Print view View original

11–20 of 123 posts

Re: Weave – A language aware merge algorithm based on entities

#11

Post by rs545837 »

keysersoze33 wrote: post #10

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...…

Hey, author here. This comparison came up a lot when weave went viral on X (https://x.com/rs545837/status/2021020365376671820).

The key difference: mergiraf matches individual AST nodes (GumTree + PCS triples). Weave matches entities (functions, classes, methods) as whole units. Simpler, faster, and conflicts are readable ("conflict in validate_token" instead of a tree of node triples).

The other big gap: weave ships as an MCP server with 14 tools for agent coordination. Agents can claim entities before editing and detect conflicts before they merge. That's the piece mergiraf doesn't have.

On bash: weave falls back to line-level for unsupported languages, so it'll work as well as git does there.

Adding a bash tree-sitter grammar would unlock entity-level merge for it. But I can work on it tonight, if you want it urgently.

Cheers,

Re: Weave – A language aware merge algorithm based on entities

#12

Post by gritzko »

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?
Almost LSP-level querying, involving versions and branches. Beagle is a revision control system like that [1]

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

Re: Weave – A language aware merge algorithm based on entities

#13

Post by rs545837 »

gritzko wrote: post #12

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? Almost LSP-level querying, involving versions…

This is the right question. Storing ASTs directly would make all of this native instead of layered on top.

The pragmatic reason weave works at the git layer: adoption. Getting people to switch merge drivers is hard enough, getting them to switch VCS is nearly impossible. So weave parses the three file versions on the fly during merge, extracts entities, resolves per-entity, and writes back a normal file that git stores as a blob. You get entity-level merging without anyone changing their workflow.

But you're pointing at the ceiling of that approach. A VCS that stores ASTs natively could answer "did any concurrent branches touch this function?" as a query, not as a computation. That's a fundamentally different capability. Beagle looks interesting, will dig into the BASON format.

We built something adjacent with sem (https://github.com/ataraxy-labs/sem) which extracts the entity dependency graph from git history. It can answer "what new uses did this function accrete" and "what's the blast radius of this change" but it's still a layer on top of git, not native storage.

Re: Weave – A language aware merge algorithm based on entities

#14

Post by deckar01 »

rs545837 wrote: post #6

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'…

Does this actually matter for multi-agent use cases? Surely people that are using swarms of AI agents to write code are just letting them resolve merge conflicts.

Re: Weave – A language aware merge algorithm based on entities

#15

Post by rs545837 »

deckar01 wrote: post #14
rs545837 wrote: post #6

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'…

Does this actually matter for multi-agent use cases? Surely people that are using swarms of AI agents to write code are just letting them resolve merge conflicts.

So that you don't feel that I am biased about my thing but just giving more context that it's not just me, its actually people saying on twitter how often the merging breaks when you are running production level code and often merging different branches.

https://x.com/agent_wrapper/status/2026937132649247118 https://x.com/omega_memory/status/2028844143867228241 https://x.com/vincentmvdm/status/2027027874134343717

Re: Weave – A language aware merge algorithm based on entities

#16

Post by SurvivorForge »

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.

Re: Weave – A language aware merge algorithm based on entities

#18

Post by rs545837 »

SurvivorForge wrote: post #16

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.

Thanks for commenting, Good question. Python was one of the trickier ones to get right. Tree-sitter parses the full AST including indentation structure, so weave knows that an indented block belongs to its parent class or function. When merging, it matches entities by name and reconstructs with the original indentation preserved.

We also handle Python class merge specifically: if both sides add different methods to the same class, weave merges them as separate inner entities rather than treating the whole class as one conflicting block. The indentation is derived from the AST structure, not from line diffing, so it can't accidentally shift a method out of its class scope.

Re: Weave – A language aware merge algorithm based on entities

#20

Post by rs545837 »

WalterGR wrote: post #19

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

We got asked this on the X thread too, when we went viral here https://x.com/rs545837/status/2021020365376671820. Your git doesn't change at all. Weave plugs in through git's merge driver interface (.gitattributes), so git still handles everything, it just calls weave for the content merge step instead of its default line-level algorithm. All your git commands, workflow, and history stay exactly the same.

For diffing arbitrary files outside git, we built sem (https://github.com/ataraxy-labs/sem) which does entity-level diffs. sem diff file1.py file2.py shows you which functions changed, were added, or deleted rather than line-level changes

Post reply on HN