11 ms·
Weave – A language aware merge algorithm based on entities
- deleted 8mo ago[deleted]
- sea-gold 8mo agoWebsite: https://ataraxy-labs.github.io/weave/ https://ataraxy-labs.github.io/weave/ I haven't tried it but this sounds like it would be really valuable to me.
- rs545837 8mo agoHaha, thanks for the feedback, yeah multi agent workflows were especially kept in mind when designing this! So I hope it helps, I am always here for feedback and feature requests.
- esafak 8mo agoAre agents any good with it?
- rs545837 8mo agoYes I designed it for agents especially, there's also weave mcp that I built that you can checkout. The good part is that this research extends really good for code review because tracking entities is more semantically rich than lines.
- kelseydh 8mo agoVery cool, would love to see Ruby support added.
- rs545837 8mo agoSome 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.
- deckar01 8mo agoDoes 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.
- rs545837 8mo agoSo 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/agent_wrapper/status/2026937132649247118 https://x.com/omega_memory/status/2028844143867228241 https://x.com/omega_memory/status/2028844143867228241 https://x.com/vincentmvdm/status/2027027874134343717 https://x.com/vincentmvdm/status/2027027874134343717
- 8mo ago
- keysersoze33 8mo agoInteresting 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/ https://ataraxy-labs.github.io/weave/
- rs545837 8mo agoHey, author here. This comparison came up a lot when weave went viral on X (https://x.com/rs545837/status/2021020365376671820 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,
- keysersoze33 7mo agoThanks for the kind offer - no urgent rush though
- rs545837 7mo agoYou will love this because we are supporting bash tree sitter grammar now with weave.
- gritzko 8mo agoAt 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 https://github.com/gritzko/librdx/tree/master/be [2]: https://github.com/gritzko/librdx/blob/master/be/STORE.md https://github.com/gritzko/librdx/blob/master/be/STORE.md
- rs545837 8mo agoThis 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 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.
- tomaskafka 8mo ago[flagged]
- SurvivorForge 8mo agoThe 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.
- rs545837 8mo agoThanks 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.
- hrmtst93837 8mo ago[flagged]
- rs545837 8mo agoReally appreciate the detail here, this is clearly hard-won experience. I agree that indentation is structural in Python.
- deleted 8mo ago[deleted]
- WalterGR 8mo agoIt’s described as a “merge driver for Git”. Is it usable independently of git? Can I use it to diff arbitrary files?
- rs545837 8mo agoWe got asked this on the X thread too, when we went viral here https://x.com/rs545837/status/2021020365376671820 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 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
- spacecrafter3d 8mo agoAwesome, I've been wanting this for a long time! Any chance of Swift being supported?
- rs545837 8mo agoSwift isn't supported yet but adding a new language is straightforward since we use tree-sitter. There's already a tree-sitter-swift grammar. Would happily accept a PR for it, if you are down for it.
- Palanikannan 8mo ago[flagged]
- deleted 8mo ago[deleted]
- rs545837 8mo agoHaha appreciate the love man! Still early days but the fact that entity-level context cuts tokens that much validates the whole thesis. Glad it's working for you, keep the feedback coming.
- CollinEMac 8mo ago>I feel git is done for good I'm either not understanding your comment or not understanding the project. Isn't this built on top of git?
- rs545837 8mo agoI think he was just being sarcastic, git's so amazing it can never be done for good. Yeah it's just a merge driver that will sit on top of git.
- Erlangen 8mo agoYou have write access to this git repo as a first time contributor. You are likely the owner of this repo as well. You made a pull request not from your own fork, but from a separate branch, https://github.com/Ataraxy-Labs/weave/pull/9 https://github.com/Ataraxy-Labs/weave/pull/9
- rs545837 8mo agoYeah he is the other contributor to the repo.
- duskdozer 8mo agoHe also was pushing code to a branch on the same repo three weeks ago: https://github.com/Ataraxy-Labs/weave/commits/fix/utf8-panic-replace-word-boundaries/ https://github.com/Ataraxy-Labs/weave/commits/fix/utf8-panic... but is acting in this post like he just discovered the project.
- taejavu 8mo agoI 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?
- rs545837 8mo agoThanks for trying it! Would love to know what the merge conflict looked like, if you can share the repo or a minimal repro, I'll dig into why it didn't resolve. That kind of feedback is exactly what helps us improve.
- 50lo 8mo agoIf 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?
- rs545837 8mo agoYes, weave detects renames via structural_hash (AST-normalized hash that ignores identifier names). If both sides rename the same function, it matches by structure and merges cleanly.
- gritzko 8mo agoThis will not work for refactors. In fact, any other change will break the hash. I know because I used this approach for quite some time.
- rs545837 8mo agoThanks a lot, I will test it out as you said, in the mean time, could you also open up an issue on the repo, so that it helps me and others to track the issue.
- _flux 8mo agoHow does it compare to https://mergiraf.org/ 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
- rs545837 8mo agoActually tackled it here: https://x.com/rs545837/status/2021423280410988580 https://x.com/rs545837/status/2021423280410988580 Cheers,
- _flux 8mo agoI think it would be interesting to include it in the comparison table, as I think it could be viewed as a base line language-aware merge tool.
- rs545837 8mo agowhat kind of compariosn table are you looking for? I actually added that on the website https://ataraxy-labs.github.io/weave/ https://ataraxy-labs.github.io/weave/
- bigcojosh 8mo agothat's pretty cool, thank you worth mentioning that mergiraf is already supported for windows. from https://github.com/Ataraxy-Labs/weave/issues/7 https://github.com/Ataraxy-Labs/weave/issues/7 it looks like it's planned for weave too at some point?
- rs545837 8mo agoYeah we are focusing on all these directions, could you also open up issues, if you want some specific things, helps us a lot in tracking issues.
- alkonaut 8mo ago> 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?
- rs545837 8mo agoI meant when they each work on a separate branch and merge back, you get the similar kinds of conflicts, where a bunch of them should not even be a conflict, so weave is trying to solve it.
- alkonaut 8mo agoI still don't understand how it makes a difference if the agent is a human or a bot?
- vidarh 8mo agoThere's no fundamental difference, but in practice the difference is one of frequency. E.g. I sometimes have 10+ agents kicking off changes to the same small project at the same time, and likely to all want to merge within the next 15-30 minutes. At that rate, merge conflicts happens very frequently. The agents can mostly resolve them themselves, but it wastes tokens, and time.
- rs545837 8mo agoThis is exactly the use case, thanks for explaining.
- rkagerer 8mo agoNo C#?
- rs545837 8mo agoC# 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.
- rkagerer 8mo agoCool! 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?
- rs545837 7mo agoThanks for notifying, I will update it. So we use a language specific parser called sem here:https://ataraxy-labs.github.io/sem/ 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.
- rs545837 7mo agoFor 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.
- ezoe 8mo agoSo 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.
- rs545837 8mo agoWhen you start seeing the diffs with entities instead of lines, is what interests me, you get much better semantic info. If you have a language specific parser, you can make a merge algorithm like weave. But the bigger win isn't resolving conflicts git shows you. It's catching the ones git misses entirely. So in those cases weave is much better, and there also other things like confidence-scored conflict classification, you should try it out it improves the agents performance, especially if you are a power user.
- orbisvicis 8mo agoIt'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.
- rs545837 8mo agoYou're right, that's a real risk, weave runs post-merge validation for exactly this, it checks entity dependencies after merge, so if one side obsoletes what the other side depends on, it warns you even when the textual merge is clean
- conartist6 8mo ago[flagged]
- Palanikannan 8mo agoand I love hacker news, this is why I pay my internet bills for
- rs545837 8mo agoyou made me emotional!
- rohitpaulk 8mo agoSaw 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/ https://ataraxy-labs.github.io/weave/
- rs545837 8mo agoThanks for sharing the website as well here. Appreciate it!
- boogerlad 8mo agoHow can this be used with jj?
- rs545837 8mo agoI had conversations with Martin, He just wants people asking for weave in their community, once people start doing it, we both can work on the integration then.
- rs545837 7mo agoCould you comment here on the PR(https://github.com/jj-vcs/jj/pull/8833 https://github.com/jj-vcs/jj/pull/8833) if you want this integrated with jj
- laalshaitaan 8mo agoThe 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?
- rs545837 8mo agoPrevention better than cure, haha, that's exactly why weave ships an MCP server alongside the merge driver.