Plenty of companies use source control other than git. AAA gaming studios are famous for not using git due to git's poor handling of large binary assets w/o workarounds.

I've used other source control systems and they do have benefits over Git to be sure. Access control is a huge one, you can have a large repository and have fine grained access control over who can access what paths in the repository. Heck with some source control systems this access control may even integrate with Active Directory, so there is only 1 account to maintain!

The way to do that with git is to have a lot of tiny repos, with all the advantages and disadvantages that brings.

Don't get me wrong, git's ability to easily branch is huge. I am totally over working in source control systems that required an admin to approve creating a branch, or where merging branches was a huge deal that could take a very long time to do, but git isn't the end all be all of source control systems, and there are certainly features from other systems that I miss when using git.

Game dev always seemed like a highly specialized thing to me. Performance critical, uses real math, lots of local instead of just server work, art assets...

I'm not saying everyone uses git, but it seems like there's probably not many people who have never had to learn it.

Especially when "knowing git" often means memorizing about 8 commands total if you're not on really big team.

When I pushed for a transition from no VCS at all to git, we couldn't use branches at first for fear that someone would need to access something and not be able to, if someone who actually knew git wasn't around.

Maybe their idea of "Can't use git" means "Can't use it well?"

I mean, a lot (most?) of the largest companies in software don't use it primarily. That being said, I agree that "knowing" git enough to for daily use is picked up very quickly. Your day to day usage of git is I'd say, medium complexity for source control. I've used tools where even cloning the repo could be a hassle, and there were nearly as many footguns as git, without reflog to recover.

Regarding large binary assets, I literally Googled "git large binary assets" and had many hits with various solutions. GitHub started offering Git LFS (Large File Storage) in 2015 -- more than 6 years ago. That said, many places still use Perforce.

It's newish (yes, 6 years is newish for projects that don't have a lot more hours, direction, and dedicated drive behind them than git-lfs seems to) and janky or unintuitive in some cases and adds another obtuse nerdy thing for e.g. artists to figure out (or be supported through) and requires extra software and server config to self-host (most of which is, uh, not as complete as one might hope) and makes backups less dead-simple than plain git and has nothing like an official server-side implementation (last I checked GH's "don't use this for production" implementation was the closest thing) and can make any kind of automation or extra tooling used with git a real pain since much of it's not lfs-aware, including some built-in git commands in certain situations (git-archive against a bare repo, for instance, which can be a super handy command in many situations).

Overall, I like it and have promoted its use and stand by that, but not every place has the time or inclination to screw around with it when they can just pay for something that solves the problem (likely Perforce).

While we're at it, git in general would be one fuck of a lot easier to support for cross-platform users and in tooling for complex projects if libgit2 caught up and took over as the official implementation. The pile-of-binaries-and-shell-and-god-knows-what-else (all living on top of a hacky, huge bundle of junk, on Windows) official Git itself is a huge impediment to doing anything with git other than just executing "git [command]" in Unixy environments. It'd also make "build my own GitHub" type projects far more tractable, cutting out some of GitHub's (and GitLab, et c.) server-side moat.

LFS is a pain, right now, even 6 years in, if you don't tie yourself to a major commercial Git host or put in a lot more effort than traditional self-hosting git requires. To reiterate: I still like and advocate it, circumstances allowing, but it definitely is not a mature solution.

I also think a lot of people in this thread don't understand that large companies don't want everyone having even read access to the entire repo.

Using a system like perforce, artists can drop files in the assets part of the repo, translators can have access to script files, and coders can have access to the parts of the code that they are working on.

Source code licenses are still a thing, where after buying a license only a certain # of people in a company are even allowed to view the licensed source code.

The way this is worked around is a build server exists where some pre-built libraries are pulled from during a developer's local machine build.

While I'm happy to no longer be working in that environment, it is unfortunate that many of the commenters cannot imagine an ecosystem different than their day to day. :/

Or use an IDE that has all that build in.