I assume the proposed system addresses it somehow but I don't see it in my quick read of this.

The semantic problem with conflicts exists either way. You get a consistent outcome and a slightly better description of the conflict, but in a way that possibly interleaves changes, which I don't think is an improvement at all.

I am completely rebase-pilled. I believe merge commits should be avoided at all costs, every commit should be a fast forward commit, and a unit of work that can be rolled back in isolation. And also all commits should be small. Gitflow is an anti-pattern and should be avoided. Long-running branches are for patch releases, not for feature development.

I don't think this is the future of VCS.

Jujutsu (and Gerrit) solves a real git problem - multiple revisions of a change. That's one that creates pain in git when you have a chain of commits you need to rebase based on feedback.

Codeville also used a weave for storage and merge, a concept that originated with SCCS (and thence into Teamware and BitKeeper).

Codeville predates the introduction of CRDTs by almost a decade, and at least on the face of it the two concepts seem like a natural fit.

It was always kind of difficult to argue that weaves produced unambiguously better merge results (and more limited conflicts) than the more heuristically driven approaches of git, Mercurial, et al, because the edit histories required to produce test cases were difficult (at least for me) to reason about.

I like that Bram hasn’t let go of the problem, and is still trying out new ideas in the space.

> ... CRDTs for version control, which is long overdue but hasn’t happened yet

Pijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it.

Not that Bram is not one of those, but the post reads like you all know what.

Engineer A intended value = 1

Engineer B intended value = 2

CRDT picks 2

The outcome could be semantically wrong. It doesn't reflect the intent.

I think the primary issue with git and every other version control is the terrible names for everything. pull, push, merge, fast forward, stash, squash, rebase, theirs, ours, origin, upstream and that's just a subset. And the GUI's. They're all very confusing even to engineers who have been doing this for a decade. On top of this, conflict resolution is confusing because you don't have any prior warnings.

It would be incredibly useful if before you were about to edit a file, the version control system would warn you that someone else has made changes to it already or are actively working on it. In large teams, this sort of automation would reduce conflicts, as long as humans agree to not touch the same file. This would also reduce the amount of quality regressions that result from bad conflict resolutions.

Shameless self plug: I am trying to solve both issues with a simpler UI around git that automates some of this and it's free. https://www.satishmaha.com/BetterGit

- What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts?

- What do teams of 1, 10, 100, 1k, etc care the most about?

- How does the modern "agent explosion" potentially affect this?

For example, my experience working in the 1-100 regime tells me that, for the most part, the kind of merge conflict being presented here is resolved by assigning subtrees of code to specific teams. For the large part, merge conflicts don't happen, because teams coordinate (in sprints) to make orthogonal changes, and long-running stale branches are discouraged.

However, if we start to mix in agents, a 100 person team could quickly jump into a 1000 person team, esp if each person is using subagents making micro commits.

It's an interesting idea definitely, but without real-world data, it kind of feels like this is just delivering a solution without a clear problem to assign it to. Like, yes merge-conflicts are a bummer, but they happen infrequently enough that it doesn't break your heart.

It’s an awesome weekend project, you can have fun visualizing commits in different ways (I’m experimenting with shaders), and importantly:

This is the way forward. So much software is a wrapper around S3 etc. now is your chance to make your own toolset.

I imagine this appeals more to DIYer types (I use Pulsar IDE lol)

[1]: https://gavinhoward.com/uploads/designs/yore.md

What I do think is the critical challenge (particularly with Git) is scalability.

Size of repository & rate of change of repositories are starting to push limits of git, and I think this needs revisited across the server, client & wire protocols.

What exactly, I don't know. :). But I do know that in my current role (mid-size well-known tech company) is hitting these limits today.

i think that's where version control is going. especially useful with agents and CI

[1] https://ataraxy-labs.github.io/sem/

    git config --global merge.conflictstyle diff3

[1]: https://github.com/samoshkin/vim-mergetool

So as long as all updates have been sent to the server from all clients, it will know what “time” each character changed and be able to merge automatically.

Is that it basically?

I recently built Artifact: https://www.paganartifact.com/benny/artifact

Mirror: https://github.com/bennyschmidt/artifact

In case anyone was curious what a full rewrite of git would look like in Node!

The main difference is that on the server I only store deltas, not files, and the repo is “built”.

But yeah full alternative to git with familiar commands, and a hub to go with it.

conflict free merging sounds cool, but doesn't that just mean that that a human review step is replaced by "changes become intervals rather than collections of lines" and "last set of intervals always wins"? seems like it makes sense when the conflicts are resolved instantaneously during live editing but does it still make sense with one shot code merges over long intervals of time? today's systems are "get the patch right" and then "get the merge right"... can automatic intervalization be trusted?

edit: actually really interesting if you think about it. crdts have been proven with character at a time edits and use of the mouse select tool.... these are inherently intervalized (select) or easy (character at a time). how does it work for larger patches can have loads of small edits?

IE if I change something in my data model, that change & context could be surfaced with agentic tooling.

Well, isn't that what the CRDT does in its own data structure ?

Also keep in mind that syntactic correctness doesn't mean functional correctness.

It's been amazing watching it grow over the last few years.

Funny, there was just a post a couple of days ago how this is false.

https://news.ycombinator.com/item?id=47359712

If you haven’t resolved conflicts then it probably doesn’t compile and of course tests won’t pass, so I don’t see any point in publishing that change? Maybe the commit is useful as a temporary state locally, but that seems of limited use?

Nowadays I’d ask a coding agent to figure out how to rebase a local branch to the latest published version before sending a pull request.

Anyway, I wanted to suggest a radical idea based on my experience:

Merges are the wrong primitive.

What organizations (whethr centralized or distributed projects) might actually need is:

1) Graph Database - of Streams and Relations

2) Governance per Stream - eg ACLs

A code base should be automatically turned into a graph database (functions calling other functions, accessing configs etc) so we know exactly what affects what.

The concept of what is “too near” each other mentioned in the article is not necessarily what leads to conflicts. Conflicts actually happen due to conflicting graph topology and propagating changes.

People should be able to clone some stream (with permission) and each stream (node in the graph) can be versioned.

Forking should happen into workspaces. Workspaces can be GOVERNED. Publishing some version of a stream just means relating it to your stream. Some people might publish one version, others another.

Rebasing is a first-class primitive, rather than a form of merging. A merge is an extremely privileged operation from a governance point of view, where some actor can just “push” (or “merge”) thousands of commits. The more commits, the more chance of conflicts.

The same problem occurs with CRDTs. I like CRDTs, but reconciling a big netsplit will result in merging strategies that create lots of unintended semantic side effects.

Instead, what if each individual stream was guarded by policies, there was a rate limit of changes, and people / AIs rejected most proposals. But occasionally they allow it with M of N sign offs.

Think of chatgpt chats that are used to modify evolving artifacts. People and bots working together. The artifacts are streams. And yes, this can even be done for codebases. It isnt about how “near” things are in a file. Rather it is about whether there is a conflict on a graph. When I modify a specific function or variable, the system knows all of its callers downstream. This is true for many other things besides coding too. We can also have AI workflows running 24/7 to try out experiments as a swarm in sandboxes, generate tests and commit the results that pass. But ultimately, each organization determines whether they want to rebase their stream relations to the next version of something or not.

That is what I’m building now with https://safebots.ai

PS: if anyone is interested in this kind of stuff, feel free to schedule a calendly meeting w me on that site. I just got started recently, but I’m dogfooding my own setup and using AI swarms which accelerates the work tremendously.

It's not the same as capturing it, but I would also note that there are a wide wide variety of ways to get 3-way merges / 3 way diffs from git too. One semi-recent submission (2022 discussing a 2017) discussed diff3 and has some excellent comments (https://news.ycombinator.com/item?id=31075608), including a fantastic incredibly wide ranging round up of merge tools (https://www.eseth.org/2020/mergetools.html).

However/alas git 2.35's (2022) fabulous zdiff3 doesn't seems to have any big discussions. Other links welcome but perhaps https://neg4n.dev/blog/understanding-zealous-diff3-style-git...? It works excellently for me; enthusiastically recommended!

Slightly disappointed to see that it is a 470 line python file being touted as "future of version control". Plenty of things are good enough in 470 lines of python, even a merge conflict resolver on top of git - but it looks like it didn't want anything to do with git.

Prototyping is almost free these days, so not sure why we only have the barest of POC here.

Is it just lack of tooling, or is there something fundamentally better about line-oriented diffs that I’m missing? For the purpose of this question I’m considering line-oriented as a special case of AST-oriented where the AST is a list of lines (anticipating the response of how not all changes are syntactically meaningful or correct).