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

111–120 of 123 posts

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

#111

Post by rs545837 »

jerf wrote: post #96
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…

Everything on a disk ends up as a linear sequence of bytes. This is the source of the term "serialization", which I think is easy to hear as a magic word without realizing that it is actually telling you something important in its etymology: It is the process of taking an arbitrary data structure and turning it into something that can be sent or stored serially , that is, in an order, one bit at a time if you really…

interesting read, will comment more once I go through everything in detail. Thanks.

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

#112

Post by rs545837 »

zokier wrote: post #88
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…

> 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. The problem is that disks (and storage in general) store only bytes so you inherently need to deal with bytes at some point. You could view source code files as the serialization of the AST (or other parse tree). This is especially apparent with LISPs and thei…

Source code is already a serialization of an AST, we just forgot that and started treating it as text. The practical problem is adoption: every tool in the ecosystem reads bytes.

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

#113

Post by rs545837 »

laalshaitaan wrote: post #110

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?

Prevention better than cure, haha, that's exactly why weave ships an MCP server alongside the merge driver.

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

#114

Post by rkagerer »

rs545837 wrote: post #75
rkagerer wrote: post #68

No C#?

C# is supported! It goes through sem-core's(the underlying library for parsing we use in Weave) tree-sitter-c-sharp plugin. Classes, methods, interfaces, enums, structs are all extracted with it. Let me know if you hit anything.

Cool! I didn't see it listed on the main page so that's why I asked. Are there a lot of languages similarly supported via plugins? Are they all listed somewhere?

Edit: Also, how are comments treated, in general (especially if they exist outside the structures you mentioned)? Eg. Does it somehow surface "contradictory" / conflicting edits made within comments? Or are they totally ignored?

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

#115

Post by rs545837 »

rkagerer wrote: post #114
rs545837 wrote: post #75

Earlier quoted context omitted.

C# is supported! It goes through sem-core's(the underlying library for parsing we use in Weave) tree-sitter-c-sharp plugin. Classes, methods, interfaces, enums, structs are all extracted with it. Let me know if you hit anything.

Cool! I didn't see it listed on the main page so that's why I asked. Are there a lot of languages similarly supported via plugins? Are they all listed somewhere? Edit: Also, how are comments treated, in general (especially if they exist outside the structures you mentioned)? Eg. Does it somehow surface "contradictory" / conflicting edits made within comments? Or are they totally ignored?

Thanks for notifying, I will update it. So we use a language specific parser called sem here:https://ataraxy-labs.github.io/sem/, you can use all the languages listed here in weave, its a seperate library. So if you want to add language support you can open a PR here.

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

#116

Post by keysersoze33 »

rs545837 wrote: post #11
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 shi…

Thanks for the kind offer - no urgent rush though

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

#117

Post by igravious »

rs545837 wrote: post #49
igravious wrote: post #47

Earlier quoted context omitted.

Nice, thanks for the Ruby support!

Of course!

Just got Kimi to use Weave to merge an official update with my (agent) modded installation (kimi-cli is open source!) and it worked a treat … kimi-cli is mostly Python (I think?!)

Fair play. Great tool.

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

#118

Post by rs545837 »

igravious wrote: post #117
rs545837 wrote: post #49

Earlier quoted context omitted.

Of course!

Just got Kimi to use Weave to merge an official update with my (agent) modded installation (kimi-cli is open source!) and it worked a treat … kimi-cli is mostly Python (I think?!) Fair play. Great tool.

Thanks for the feedback, pumped up to hear that.

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

#119

Post by rs545837 »

keysersoze33 wrote: post #116
rs545837 wrote: post #11

Earlier quoted context omitted.

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

Thanks for the kind offer - no urgent rush though

You will love this because we are supporting bash tree sitter grammar now with weave.

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

#120

Post by rs545837 »

rkagerer wrote: post #114
rs545837 wrote: post #75

Earlier quoted context omitted.

C# is supported! It goes through sem-core's(the underlying library for parsing we use in Weave) tree-sitter-c-sharp plugin. Classes, methods, interfaces, enums, structs are all extracted with it. Let me know if you hit anything.

Cool! I didn't see it listed on the main page so that's why I asked. Are there a lot of languages similarly supported via plugins? Are they all listed somewhere? Edit: Also, how are comments treated, in general (especially if they exist outside the structures you mentioned)? Eg. Does it somehow surface "contradictory" / conflicting edits made within comments? Or are they totally ignored?

For comments: weave bundles doc comments (JSDoc, ///, /* */, etc.) with the entity they belong to. So if one branch edits a doc comment and another edits the function body, they merge as part of the same entity. Standalone comments between functions are treated as interstitial text and merge normally.
Post reply on HN