It feels like a Pareto Principle problem. 80% of source control is text files that can be three-way merged as text files, but a lot of hard problems are in that 20% that isn't.

Git does very well at the 80% and with tools like custom merge tools and git lfs/annex and git sparse "cone" checkouts can get pretty close to hitting the 90 or 95% case.

But yeah, so many of those extra tools in that 80 to 90% area are awful to work with because they aren't the default, aren't out the box, are hard to configure and get right. Partly because it always seems like there will be a gap in that 95%-100% window and partly because the use cases that need that 80% to 90% often are only "just 10% of use cases".

(Which is also to say that to survive Jujitsu and Pijul and others seem to have to work to make sure they handle the 80% base case extremely well just to compete with git, they haven't necessarily time to think about the 90% or 100% problem.)

(ETA: And also relates to why game development seems to feel the 20% cases more, because by volume of data game development is certainly closer to a flip of the 80/20 sides with 80% or more large binaries by volume.)

I would say that at least the submodule problem is more like the last 45%. Every single company I've worked in has ended up using submodules and it always ends up causing huge amounts of pain because they suck.

The only alternative Git offers, which is slightly better IMO, is monorepos. But they're only slightly better - they also have really significant downsides.

I'm 100% sure there's a much nicer solution to the kinds of problems people use submodules for that isn't submodules, but as far as I can tell zero people are trying to find it, despite it being such a universal problem.

From my viewpoint, a lot of the submodule problems are effectively same as the monorepo problems, including how you end up with both problems. There certainly are factorings of projects into "microservices" and moving the dependency management problems out of source control to package managers of different types. Microservices and package management sure do have their own problems and trade-offs and there isn't a "universal solution", just what side of the trade-offs you prefer to be on.

That it is difficult to merge e.g. media files has nothing to do with Git. It's just that it is one of the core assumptions in Git, that it is fine to diverge locally and cheaply, because you can just merge. I think this can't really be solved without a centralized server and that is just something, that Git doesn't want to be.

Yeah, decentralization is an important principle to git and tools to manage concurrency such as "file locking" become a lot harder to do in an a decentralized way than a centralized one. (Pijul has the same problems because decentralization is also an important principle to it.) It is something of a problem space that transcends beyond git. But I also think this is how we've arrived to this moment where the best source control tools have decentralization as an important principle. That 80% case with easy mergeable text files is a lot nicer to work with in a decentralized world because it is "offline-first" and quite capable. It often seems, across a lot of different styles of software development, worth the trade-offs that things like media files are harder to work with. (Again, realizing the obvious problems with game development where that often flips and the majority of work is often in the media file assets as much or more than the text files.)