alt Hacker NewsOne of the many points of git's design is that most of the steps you need to do in P4 are not necessary at all. You do not "lock assets", you do not "release them", there is no "merging into streams" equivalent.
The entire workflow with git avoids huge amounts of the cognitive load of using P4, which in turn means that integration with IDEs becomes much less important.
I worked with P4 around the time I first started learn git (coming to both from SVN). P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git". So glad to be far, far from that particular tool now.
Replies
> You do not "lock assets",
Uhhhhhh. Locking binary assets is ABSOLUTELY NECESSARY in Git. Except Git can't actually do that. So what locking binary assets Git looks like in practice is an unenforced message in Slack saying "hey I'm changing this file please no one else touch it".
Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.
> there is no "merging into streams" equivalent.
Weird take. Streams is Perforce's mediocre take on Git branches. P4 stream merge is close enough to Git branch merge that I would say they're in the same family.
> P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git".
And yet Git has almost zero mind share in gamedev because it doesn't solve the problem.
P4 is somewhat mediocre. And it's made zero improvement in ~8 years since getting bought up by PE.
But I can also teach a game designer or artist who has never heard of source control how to correctly and safely use P4 in about 15 minutes. Meanwhile you can tell Git is badly designed because there are 10,000+ tutorials explaining how easy it is! Spoiler: things that are actually easy do not need 10,000 tutorials telling you that it is easy.
Solving merge conflicts on text-based files is infinitely easier than binary-based. It's not a useful comparison.