by shubhamintech
0 subcomment
- 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?
- 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?
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
- 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
by keysersoze33
1 subcomments
- 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/
by rohitpaulk
1 subcomments
- 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/
- 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?
- 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.
by orbisvicis
1 subcomments
- 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.
by spacecrafter3d
1 subcomments
- Awesome, I've been wanting this for a long time! Any chance of Swift being supported?
by boogerlad
1 subcomments
- 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.
by SurvivorForge
2 subcomments
- 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?
by Palanikannan
4 subcomments
- [flagged]
by conartist6
2 subcomments
- [flagged]