What if Merges Understood Your Code?

Git's three-way merge is one of the most elegant algorithms in everyday software engineering. Take the common ancestor of two branches, compare what each side changed, and combine the results. It's fast, predictable, and it works remarkably well considering it has no idea what the content it's merging actually means.

But every developer has had the experience of getting a merge conflict that didn't feel like a real conflict. Alice adds a parameter to process_payment(). Bob adds logging to validate_order(). These are completely independent changes to different functions that don't share any logic or state. But because the two functions happen to sit next to each other in the same file, git's merge algorithm sees that the surrounding context lines overlap and conservatively reports a conflict.

The reason this happens is that git's merge is, by design, working at the line level. It can see that two branches both modified lines near each other, but it can't see that those lines belong to different functions and therefore can't possibly interfere.

To understand why this matters increasingly over time, think about it in terms of how conflict probability scales. If you have K workers (humans or agents) making changes to a codebase, and a file contains E independent entities, the probability of a true conflict follows birthday-paradox-style scaling: it's roughly proportional to K²/E. As K grows, the gap between true conflicts and reported conflicts widens — quadratically.

This is where agents make the problem acute. A human developer can pause, look at a false conflict, realize the two changes don't interact, and resolve it in a minute. An agent can't do this nearly as cleanly. Merge conflicts break the agent's workflow. Every false conflict is a point where the agent's pipeline stalls or degrades.

So we built Weave as a git merge driver. It plugs directly into git's existing merge pipeline. You don't change your workflow at all. You still use git, still use branches, still merge the way you always have. The only difference is that when git encounters a file that both branches modified, Weave steps in and parses all three versions of the file into structural entities using tree-sitter: functions, classes, methods, imports. It matches entities across versions by name, and then merges each entity independently.

For agents, confluence is the critical property, because it lets an agent know before it starts working whether its changes will merge cleanly. If an agent is about to edit entity X, and it can check that no other agent is currently editing X, it has a mathematical guarantee that its work will merge. It doesn't need to hope, or retry, or call an LLM to resolve conflicts afterward.