I think this is a great idea, and I've wondered about something like this before.
I do find it sad though that the opening description has to be:
> Two agents edit different functions in the same file? Clean merge.
Why does EVERYTHING has to be geared towards agents? Humans can use this too. Why not just "two commits contain edits for different functions in the same file?"
joshka 11 hours ago [-]
Automated process run into race conditions more often due to their frequency.
Humans can do that too, but are less likely to in practice both due to lower frequency and because they carry more awareness of global context that isn't captured in systems that aren't checking for it. The ability of your brain to read and take as context all the pull requests open in a repo that might affect your work.
rapnie 9 hours ago [-]
> Why does EVERYTHING has to be geared towards agents?
This was also my first thought when I checked the website. I was interested in the general merge approach, and that it works with LLMs and agents fine, but that's secondary. Nowadays every product must be in-your-face AI-first somehow, often to the extent that it de-emphasizes why the product exists in the first place, its core competency and distinguishing features pushed below the fold by screaming "It supports AI" headlines. It saddens me. That something supports AI is nothing special anymore, an expected feature. Just mention it like that, in the product highlight box next to where it mentions that it supports Github or similar nothing-special features.
znpy 12 hours ago [-]
> Why does EVERYTHING has to be geared towards agents?
Moving forward one can expect the most amount of code to be generated by agents, so it makes sense to optimise for that use case.
(Note that i’m not saying it’s good or bad)
chrisandchris 7 hours ago [-]
> the most amount of code generated by agents
Yes, I wholehartly agree. Coming from a week of agent-coding - out of pure curiosity - most code was generated by agents, which I had then to delete and rewrite to use like a quarter of statements to achieve the same, in an understandable, maintainable way.
But that's just my experience.
jstanley 6 hours ago [-]
People will very often say they "had to" do something, when in reality they merely "chose to" do that thing.
zahlman 11 hours ago [-]
> so it makes sense to optimise for that use case.
How do the agent and human use cases meaningfully differ here, though?
I'm pretty sure GP's complaint is about the prose description, rather than the actual functionality.
nijave 7 hours ago [-]
I suspect it's much worse with agents. They tend to generate a lot more code and also more likely to make large refactors.
From the parent, making edits to different functions in the same file usually doesn't cause a merge conflict unless they're close together. Usually it's when you have the same lines being replaced with 2 different options.
I think humans naturally tend to try to avoid working on the same area of the codebase at the same time and have other mitigations like daily meetings to coordinate and organize.
That said, yeah, I think they're complaining about "slap AI on everything" as well
rohanat 12 hours ago [-]
Totally fair. The merge logic doesn't care whether a human or an agent wrote the commit, "two commits touch different functions in the same file, clean merge" is exactly how a human should read it too. We lead with agents because that's where merge volume is about to explode and the pain is worst, not because it's agent-only. Point taken on the copy, I'll make it less exclusionary.
gwerbin 7 hours ago [-]
I've genuinely had this problem in teams as small as 3 and it's a genuine headache. It's even a problem when you're working solo!
What I want is a comparison with other improved diff/merge drivers like difftastic/mergiraf.
11 hours ago [-]
zx8080 11 hours ago [-]
> Software, written for the things that read it.
> humans are slow, forgetful, and can only hold a few things in their head at once.
Thank you very much for stating it all up-front.
hmokiguess 6 hours ago [-]
On the point around agent collaboration with this, I think there's a larger opportunity in the agent to agent protocol over git beyond just semantic merge.
https://github.com/h5i-dev/h5i has caught my attention lately and I have been meaning to explore this more, I feel like git workflows are leveling up fast since worktrees become ubiquitous and agentic development exposed more how it can unlock parallelization
willrshansen 14 hours ago [-]
First image I see should be a difference of how the merges work.
rohanat 11 hours ago [-]
Thanks a lot for this feedback, you are right, but I actually had a page about the merge algorithm more in depth, maybe you will love it.
oe 10 hours ago [-]
Could you link to it? I couldn’t find it on your site.
krater23 10 hours ago [-]
The AI thougth it's better to just show the result in a stupid manner. I expect the software AND the website are mostly AI generated.
nijave 7 hours ago [-]
Maybe it is time to reintroduce agents to Extreme Programming. Mainly leaning into frequent integration (putting the continuous back in CI)
Imo merge conflicts are usually a symptom of another problem like poor coordination, poor architecture, too big of change sets, branches that are too long lived. I think the most common case I hit them is conflicting package lock file updates but merging is usually useless there. For lock files you usually just pick one version then have the package manager update it.
psYchotic 14 hours ago [-]
Without having looked into how Weave works, it sounds similar to Mergiraf: https://mergiraf.org/
rapnie 14 hours ago [-]
There's a benchmark on the site that compares with mergiraf.
There's (at least) one example where I'd rather have a conflict:
> Python: both add decorators to function
If two branches add a decorator into the same function, I definitely want to keep both, but the _order_ is of great importance.
But in fact, this makes me think that automated semantic resolution can have a lot of issues. E.g:, say two branches add the following two lines separately. Merging them requires a human considering the order of operations and how the affect the result:
title = title.replace("_", " ")
title = title.to_title_case()
v1ne 9 hours ago [-]
I tried to read this, and what the tool works, but this is so much text with little context. Looks like AI fluff. It sounds pretty straight-forward, so this should be a single page with a few paragraphs only.
usrnm 9 hours ago [-]
At this point I just ask an LLM to resolve conflicts, works most of the time. An LLM can not only understand the language, it can also understand the intent behind both changes, which leads to much better results
Does this _need_ to be language specific, semantic and smart? Just a word-based diff would be so much better than a line-based diff.
javier2 8 hours ago [-]
How do I use it in my normal flow?
Edit: the readme on github explains quite well
dash2 13 hours ago [-]
If it is worth trying out, it is worth writing the README for.
rohanat 11 hours ago [-]
Yeah you can find the readme on the github repository.
igravious 12 hours ago [-]
This tool does not work. I wanted it to work. I wanted to automate merges with AI supervision. No dice. Silent corruption that wouldn't go away no matter how many issues I filed. Unacceptable. Had to disable it. https://github.com/Ataraxy-Labs/weave/issues?q=is%3Aissue%20... Be warned.
nullbio 7 hours ago [-]
I had the same problem. Was using this a few months ago, had it running for weeks, and noticed that code was disappearing. I no longer use it. Aside from that, I decided there's no point anyway, considering that LLMs are great at figuring out merge conflicts.
rohanat 11 hours ago [-]
I am sorry about your experience igra, but to be fair, yeah there are some failure cases but I love to receive any feedback that you think can improve it and make it a more generalized solution.
BrandiATMuhkuh 13 hours ago [-]
Pretty cool.
I always thought merges should happen by comparing the AST and not lines
rohanat 11 hours ago [-]
Thanks a lot for the feedback, appreicate it!
satvikpendem 14 hours ago [-]
How does it compare to SemanticDiff extension?
rohanat 11 hours ago [-]
Different layer. SemanticDiff is a language-aware diff viewer, it helps you read a change. weave is a merge driver, it resolves the three-way merge so you get fewer conflicts in the first place. The closer analog to SemanticDiff in our stack is sem diff.
csomar 13 hours ago [-]
I'm working on an online diff tool (https://codeinput.com/products/merge-conflicts) and recently added a mergiraf integration. Basically, the tool loads your git merge but uses mergiraf as the resolution driver. Then add these auto-resolved files to the editor instead of auto-resolving directly.
I also tried out weave, but apart from TypeScript, I haven't found any cases where it actually outperforms mergiraf (I run a bot that watches for new merge conflicts on GitHub, so I've got a steady stream of conflicts to test against).
I reached out a couple months ago on Reddit, but I don't think we ever landed on a time to talk. Would be interested to re-connect again.
rohanat 11 hours ago [-]
This is great, and sorry we never landed a time after Reddit, that one's on me. Let's actually fix it, could you email me on rohan@ataraxy-labs.com.
For context on where the gap might be: weave matches at the entity level (functions/classes/methods by name + type + scope) and uses structural hashing for rename/reorder detection, so it should shine on reorders, renames, and large same-file edits, and may be at parity elsewhere. If your stream tags conflicts by language and type, comparing where each driver wins would be useful to both of us.
basurayshreyan 16 hours ago [-]
how does it fare on organisation repos ? Its quite tricky to make it work on org plans where git based merge goes through a lot of code scannings and stuffs i guess. Curious to know about that
rohanat 16 hours ago [-]
Good question. Weave is a standard git merge driver, so it slots into the existing flow rather than replacing it. You wire it up in .gitattributes, and it only changes the 3-way conflict-resolution step that git already runs. The output is a normal merged tree, so everything an org layers on top still runs unchanged: branch protection, required status checks, code scanning, CI. It isn't bypassing any of that. It just resolves conflicts by entity structure (functions, classes, methods) instead of line hunks, then hands a regular file back to git.
IshKebab 6 hours ago [-]
Website is pure slop, but I'd really like more tools like this. Can any human confirm if this is actually any good?
Also if any of the slopperators want to make something really useful, can we get a decent `git diff` GUI that detects moved/copied lines across files? As far as I know the only tool that does this is `git diff --color-moved` but reviewing diffs in the terminal sucks, and it drops all information about where the code was moved/copied from.
VSCode has something experimental for this but it doesn't work across files as far as I know.
satvikpendem 4 hours ago [-]
SemanticDiff, difftastic, Delta should work.
skeledrew 6 hours ago [-]
Sucks to be you. If you really want to know if it's good, deal with the slop yourself instead of trying to get another to do the work for you.
jimmypk 6 hours ago [-]
@rohanat How does Weave handle a semantic dependency that crosses entity boundaries, such as one branch changing a function signature while another changes one of its call sites? The entities are distinct, so a structural merge can be textually clean while producing a type error or subtly stale behavior. Is the intended correctness boundary parse-valid output, or do language-server/compiler checks participate before the merge is accepted?
franticgecko3 13 hours ago [-]
[dead]
DonHopkins 9 hours ago [-]
Too bad Trump hijacked the meaning of the word "weave" to mean senile "sunsetting" and rambling incoherently from unrelated topic to topic, swerving between conversational lanes and colliding with facts and laws and decency like a sleepy angry drunk driver off his meds.
Rendered at 19:23:06 GMT+0000 (Coordinated Universal Time) with Vercel.
I do find it sad though that the opening description has to be:
> Two agents edit different functions in the same file? Clean merge.
Why does EVERYTHING has to be geared towards agents? Humans can use this too. Why not just "two commits contain edits for different functions in the same file?"
This was also my first thought when I checked the website. I was interested in the general merge approach, and that it works with LLMs and agents fine, but that's secondary. Nowadays every product must be in-your-face AI-first somehow, often to the extent that it de-emphasizes why the product exists in the first place, its core competency and distinguishing features pushed below the fold by screaming "It supports AI" headlines. It saddens me. That something supports AI is nothing special anymore, an expected feature. Just mention it like that, in the product highlight box next to where it mentions that it supports Github or similar nothing-special features.
Moving forward one can expect the most amount of code to be generated by agents, so it makes sense to optimise for that use case.
(Note that i’m not saying it’s good or bad)
Yes, I wholehartly agree. Coming from a week of agent-coding - out of pure curiosity - most code was generated by agents, which I had then to delete and rewrite to use like a quarter of statements to achieve the same, in an understandable, maintainable way.
But that's just my experience.
How do the agent and human use cases meaningfully differ here, though?
I'm pretty sure GP's complaint is about the prose description, rather than the actual functionality.
From the parent, making edits to different functions in the same file usually doesn't cause a merge conflict unless they're close together. Usually it's when you have the same lines being replaced with 2 different options.
I think humans naturally tend to try to avoid working on the same area of the codebase at the same time and have other mitigations like daily meetings to coordinate and organize.
That said, yeah, I think they're complaining about "slap AI on everything" as well
What I want is a comparison with other improved diff/merge drivers like difftastic/mergiraf.
> humans are slow, forgetful, and can only hold a few things in their head at once.
Thank you very much for stating it all up-front.
https://github.com/h5i-dev/h5i has caught my attention lately and I have been meaning to explore this more, I feel like git workflows are leveling up fast since worktrees become ubiquitous and agentic development exposed more how it can unlock parallelization
Imo merge conflicts are usually a symptom of another problem like poor coordination, poor architecture, too big of change sets, branches that are too long lived. I think the most common case I hit them is conflicting package lock file updates but merging is usually useless there. For lock files you usually just pick one version then have the package manager update it.
https://ataraxy-labs.github.io/weave/benchmarks.html
> Python: both add decorators to function
If two branches add a decorator into the same function, I definitely want to keep both, but the _order_ is of great importance.
But in fact, this makes me think that automated semantic resolution can have a lot of issues. E.g:, say two branches add the following two lines separately. Merging them requires a human considering the order of operations and how the affect the result:
Edit: the readme on github explains quite well
I also tried out weave, but apart from TypeScript, I haven't found any cases where it actually outperforms mergiraf (I run a bot that watches for new merge conflicts on GitHub, so I've got a steady stream of conflicts to test against).
I reached out a couple months ago on Reddit, but I don't think we ever landed on a time to talk. Would be interested to re-connect again.
For context on where the gap might be: weave matches at the entity level (functions/classes/methods by name + type + scope) and uses structural hashing for rename/reorder detection, so it should shine on reorders, renames, and large same-file edits, and may be at parity elsewhere. If your stream tags conflicts by language and type, comparing where each driver wins would be useful to both of us.
Also if any of the slopperators want to make something really useful, can we get a decent `git diff` GUI that detects moved/copied lines across files? As far as I know the only tool that does this is `git diff --color-moved` but reviewing diffs in the terminal sucks, and it drops all information about where the code was moved/copied from.
VSCode has something experimental for this but it doesn't work across files as far as I know.