Weave: Merging based on language structure and not lines(ataraxy-labs.github.io) |
Weave: Merging based on language structure and not lines(ataraxy-labs.github.io) |
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.
What I want is a comparison with other improved diff/merge drivers like difftastic/mergiraf.
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.
> 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.
> 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()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.
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.
Edit: the readme on github explains quite well
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.
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
If the industry is using agents and shipping a certain amount X of code/features in a certain amount if time, you either start using agents as well or you fall behind.