[bitwize]

Git is terrible for real-world development, and it's a damn shame that industry has standardized on it. For something like the kernel, which is managed as a series of patches, it's fine, but so many real-world projects depend on large amounts of binary assets or data. Where is the most logical place to put these? The repo.

Guess what you CAN'T do efficiently with Git :)

So a lot of industrial Git users have to do these contortions involving S3 buckets, etc., or else reinvent their own bespoke versions of Git (like Microsoft GitVFS) in order to stand up a working tree on a fresh machine. Plus those external dependencies need to be kept track of, updated, and the updates kept track of.

We used to have an industrial-strength VCS that could handle source code, binary data, and huge repositories of both very efficiently: Perforce. Which is kind of on private-equity life support now.

[nuancebydefault]

The problem of versioning binaries is more fundamental, not tied to the tool.

Binary assets themselves don't belong under traditional source control because they are not suitable to be diffed. That is why git LFS stores them seperately and only versions their hashes.

[azornathogron]

Although I think it's extremely unlikely, I almost wish subversion would have a resurgence. I like git, personally, but I've seen so many people struggle with it, and the problems of putting large/binary assets into the repository are real. Yes, there's LFS now, but (as far as I know) you then need to make up front decisions about what to store directly and what to store indirectly as LFS objects.

[nuancebydefault]

Subversion was much better than anything existing before, but a very fundamental problem is that it treats branches and tags, which are conceptually different, the same way. This results in branches not tracking well their history and tags behaving like moving targets.