[danbolt]

You’re absolutely right, but larger developers and publishers have been slower to adopt.

P4’s GUI/model is also intuitive for non-programming roles to learn and use historically compared to git, so a team with wide skills can ramp up quickly with a unified toolset. A less-technical manager gets a GUI that has versioning across changes from a multidisciplinary team. You can probably guess what inertia that has in a space with higher turnover compared to other industries.

As mentioned, things are changing though. git and GitHub have become a mainstay and are what new programmers likely learn in schools. This has a trickle effect on new projects with smaller teams and results in more investment into git setups. I use git in a AAA context at work, and it’s not uncommon to find sentiments from more seasoned game programmers on git that are similar to HN comments about the latest fad in web frameworks.

[jfkebwjsbx]

The problem is that you blamed Git, rather than your legacy workflows and corporate culture.

And again, you keep blaming Git here, now around a lack of intuitiveness and a lack of GUI. Again, Git has multiple GUIs around to choose from and multiple integrations with almost any editor and IDE you can think of, some meant for beginners and trivial usage.

And no, things are not "changing" and Git is not to be compared with a "web framework fad". Git became the version control system more than 5 years ago.

[danbolt]

Sorry if my tone came off as blaming like you said. I didn't mean to be blaming git or holding it responsible for something. I see a lot of existing inertia for Perforce in the AAA game development industry, and wanted to express that.

I think you're correct in that git is the go-to version control software. I'd reach for it as a default tool every time. I do work with older programmers where the majority of their careers have been in Visual C++ and Perforce, and I've definitely heard sentiments seeing it as wheel-reinventing. I don't agree with them, but it's what I've experienced.

[dagmx]

So I fully agree with you, but one area for more artist heavy workflows where git still struggles is ease of use.

The two biggest issues are: - git lfs doesn't automatically identify large files or binary files. So it's very easy for even experienced engineers to have set up lfs but forgotten to track a file or extension

- git exposes too much of its internals. It's really cumbersome for artists even with UI tools.

That's not to fault git as a technology but I think there's a place for an artist friendly layer on top of git, perhaps a very artist centric UI and set of tools and workflow guides