[squidgedcricket]

It's funny, and common, to hear new-learners complain that git's too complex. It's so much better than all the alternatives, and 99% of the time it's incredibly simple to interact with.

Definitely feels a little weird to be the one saying 'back in my day, we had to walk 2 miles up hill, both ways, to commit our code. and lord help you if you needed to submit a patch.'

[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.