[mikey-k]

Interesting idea. While conflicts can be improved, I personally don't see it as a critical challenge with VCS.

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.

[procaryote]

What kind of scalability issues have you had with git?

Is it because of a monorepo?

[mikey-k]

yes - monorepo. Git (and associated service providers) have a lot of work to do to scale out to large organizations working in a single code base.

"Better Merge Conflicts" is not on this list.

Although I'm sympathetic to the problem, and I've personally worked on "Merge Conflicts at Scale". Some of what's being suggested here is interesting. I question if it makes a material difference in the "age of ai", where an AI can probably go figure out enough context to "figure things out".

[adastra22]

Merge conflict avoidance is not a monorepo issue. In fact, the whole purpose of a monorepo is to avoid these sorts of issues, so it's not surprising.

Merge conflict hell shows up when, for example, you maintain a long-lived feature branch periodically rebased against an indifferent upstream that has its own development priorities.

I've maintained a project for years that was in this sort of situation. About ~100 commits on top of upstream, but invasive ones that touched nearly every file. Every six months upstream did a new tagged release. It would take me literally weeks of effort to rebase our patches on top, as nearly every commit triggered its own merge conflict hell.

You don't encounter these sorts of issues in a monorepo.

[layer8]

One solution is to decompose your code into modules with stable interfaces and reference them as versioned dependencies.