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?"
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
> 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.
First image I see should be a difference of how the merges work.
Without having looked into how Weave works, it sounds similar to Mergiraf: https://mergiraf.org/
How do I use it in my normal flow?
Edit: the readme on github explains quite well
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.
If it is worth trying out, it is worth writing the README for.
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.
Pretty cool. I always thought merges should happen by comparing the AST and not lines
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.
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.
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
[dead]
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.