Perforce has a locking mechanism for files, which is important for the large binary objects that are used in game development. Git doesn't really have that concept, so it requires more out of band communication to make it work for that use case.
Git LFS might handle this, but it's just not something that Perforce shops have to even think about, train their people on, etc. It's just "there" and there's somebody that they can call and yell at if things go wrong.
Of locking files? Sure it does; if two people modify the same piece of code, then there will be a merge conflict, and whoever's doing the merge will have the opportunity to reconcile those two versions. It's like a lock, but you don't have to think about it / explicitly lock and unlock the object you're editing. Combine this with rebasing (git-speak for "switch to the branch into which I want to merge and then try applying all the changes from my branch") and you end up with a pretty coherent idea of what changed and in what order.
Having used both branch-oriented (like Git) and locking-oriented (not Perforce specifically, but my current dayjob involves very similar version control schemes), I vastly prefer the former. Less ceremony around doing things in parallel, and less risk of development deadlocks (e.g. Alice locked A.cpp for editing, Bob locked B.dds for editing, Alice now wants to edit B.dds, Bob now wants to edit A.cpp, now Alice will have to revert her lock on A.cpp, wait for Bob to do everything he needs to do, then relock A.cpp and redo her changes all over again (probably also having to debug new things because of new bits and pieces Bob added) - or Bob will have to do so for B.dds - and cue fistfight in the breakroom).
----
That all being said, binary files are indeed a weak spot for Git, so if you really do want to version control your textures and models and sounds and such, then sure, perhaps a different VCS tailored for that use-case would be more ideal. In my experience, though, that tends to be an anti-pattern; generally better to keep code and assets separate (I'm well aware that tools/engines like e.g. Unity don't play the slightest bit nicely with that separation), using separate version control systems tailored to the specific content.
Merge conflicts are definitely not the same thing as file locking. At the point where you're getting a merge conflict, it's too late. How are you going to resolve conflicts in an audio file?
File locking is a way to communicate in advance that nobody should attempt to make changes to a particular file until the lock is cleared. Merge conflicts are communication in arrears (so to speak) and at that point, effort has already been wasted by at least one person.
> How are you going to resolve conflicts in an audio file?
By choosing one and discarding the other, or by creating a new audio file that incorporates both changes, just like one would do for any other file.
While I don't know if this exists, there's nothing theoretically preventing the creation of a diffing/patching tool for audio/video files, detecting insertions/deletions/replacements (perhaps by timestamp/frame rather than by line) the same way `diff` does for text.
> at that point, effort has already been wasted by at least one person.
A file lock doesn't prevent that time waste; there's nothing stopping someone from immediately overwriting it as soon as the first editor commits/releases the lock (in which case the first edit was a complete waste of time).
I don't quite think you understand how perforce works.
Locking the file is a signal not to work on it because someone else is modifying it. There isn't currently software that supports semantic merging of audio or video, so perforce says "someone is recoloring the asset, don't change the animation until they're done, or you'll just have to do the work again".
In the meantime, perforce prevents you from checking the file out. So you have to explicitly and clearly bypass your source control to do what you suggest, at which point someone rightfully yells at you.
> Locking the file is a signal not to work on it because someone else is modifying it
I know how file locking works. Like I've said before, my day job involves using a locking-based version control system. My disdain for locking-based version control comes specifically from having to put up with it instead of using something sane like Git.
> So you have to explicitly and clearly bypass your source control to do what you suggest, at which point someone rightfully yells at you.
And yet that will inevitably happen anyway, because someone's breathing down your neck to get that animation done and won't take "well I'm waiting for Bob to finish recoloring first" as an answer. Cue the aforementioned fistfight over whether Alice's animation or Bob's recoloring can happen first.
Or it'll inevitably happen due to the aforementioned risk of deadlock (Alice is tweaking animations in a different order than Bob is tweaking textures, and thus run into a situation where both are waiting on the other to release locks on files; cue fistfight).
I've seen both cases happen repeatedly. All of those cases would've been avoided had we used a version control system that used branches and merges instead of locks and unlocks.
A lock prevents you from opening it to edit in the first place, without warnings that "so and so user is currently editing this, are you sure you want to open this as read-only?". This reduces accidental time waste (and computer systems shouldn't try to protect people from deliberately wasting their own time, because they probably aren't).
I think we're gonna have to agree to disagree on that. I've found that locking a file from any changes entirely almost always causes more problems than it ostensibly solves, and is a massive impediment to productivity on any team larger than a single person. The vast majority of the time it's entirely unnecessary anyway.
Absolutely agree with you when it comes to textual/structural information where merge conflicts can be solved easily. But for binary like formats, I feel often there is no way to resolve a conflict.
Indeed I do not. If game developers (and/or game engine developers; looking at you, Unity3D...) showed similar restraint, then they likely wouldn't feel the need to tie themselves to 90's-esque version control schemes.
From what I've seen, perforce is better for storing binary intermediates.
Git doesn't work very well with partial or subfolder checkouts which is something you would need if you want to store intermediates. In games intermediates can take multiple hours to build (like maps). Building the game from scratch every commit like it's usually done with git CI tooling does not work very well.
We also ran into wanting to give modders access to maps and materials but not to game code.
Git LFS might handle this, but it's just not something that Perforce shops have to even think about, train their people on, etc. It's just "there" and there's somebody that they can call and yell at if things go wrong.