Also, "exclusive checkout" is something that doesn't even really make much sense in git, but is important for people collaborating on non-mergeable assets (3D models, textures, etc). We end up using git for code and in-game assets but p4 for source art assets.

Some small game studios also don't use git. Famous indie developer Jonathan Blow[1] said they had 20GB of data on a svn repo 6 months ago: https://news.ycombinator.com/item?id=6745412#up_6746172

[1] Braid here if you haven't: https://www.youtube.com/watch?v=uqtSKkyJgFM

Perforce also handles large binary blobs better as well, which is super important in game programming.

Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git).

We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art.

This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.

How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.

It's not the GUI that's the problem. The difficulty comes when you pull/fetch-merge and somebody has pushed a change in a file you're editing. Binary files aren't easy to merge, so now you're going to lose your changes, or they're going to lose theirs. This is the problem the check in/check out (lock/unlock, whatever) mechanism is designed to solve. It gets in your way a bit when working on files that could be automatically merged, but it's completely necessary when working on files that can't.

A system like perforce stores the files read-only on disk, and makes them writeable when you check them out. To do that you visit the perforce GUI and try to check the file out; if somebody else has the file checked out already, the server will tell you who it is, so you can go and talk to them and decide how you're going to order the edits.

(Because of the read-only flag, even if you don't check out at least the files you know you'll need before you start work (which you should do), you at least find out immediately when you try to save. So even if you then end up losing a bit of work - it happens - you at least won't get too far into your work before finding this out.)

I think the bigger point is that game studios check in assets. And you don't want the complete history of game assets over 2 years of development and iteration on your machine. And git is generally not optimized for huge binary files.

git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets).

This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid.

http://stackoverflow.com/questions/3055506/git-is-very-very-...

FWIW, git will never store two copies of the exact same file in the same repository, since the blobs will have the same SHA-1 hash.

Right. But when you change one thing in the the PSD git can't do a diff and store the diff. Which means you now have basically the same 500meg file duplicated.

SVN and the like will attempt to store the binary deltas instead of duplicating the files. I don't believe git can actually do this due to the way branches / git itself works (it doesn't have a simple #1 - #2 - #3 ... #n commit chain setup)

There are plugins for handling binary assets better but they aren't great. and/or it just makes it less intuitive for the non-programmers which really defeats the whole purpose.

I absolutely _love_ git and I'm 99% sure this issue will be worked out at some point. I've seen teams just use git for the code and then use something else for art assets (alien brains or something).

Git packs are mostly made up of deltas. Git is remarkably efficient at diffing files. And because it's all handled at the the storage level it doesn't matter what order the files are in, it generally packs all the revisions of a file from largest to smallest with the a compression window several versions wide. The problem is that it's still a lot of data when you have significant binary assets.

Edit: The default is to delta files up to half a gigabyte in size.

Sure, but that rarely matters here, as artists are working on the assets.

Having used both extensively, Perforce workflow is just a lot easier for a layperson to understand. Add files to changelist, move files between changelists, remove file from changelist, check it in. It has a nice GUI and command line tools. With git you have staged files vs commited files, commit vs push, multiple commits and the need to rebase, difficulty of removing a file from the commit before push, not to mention lack of a good built in visual merge solution tool and stuff like detached head state. Git also has a more complex command line, and multiple UI choices, none of which are great. I love git and it is my vcs of choice, but just because we know, love, and understand it doesn't mean intern Katie from the art team is going to feel the same way.

I think perforce deals with binary files better too (not sure of the details)

And what when, suddenly, vim appears and they have no idea of why or how to close it?

At what point would Vim appear when using a gui client for git?

the github client is actually extremely artist friendly.

Not much commercial game development goes on on github, which IIRC is the only way to use the github client. (Where I work we have a local gitlab.)

Since commercial developers on github presumably use private repositories, how would you tell?

You can use the github client with non-github repos as well.

But not particularly stable. At least when I tried to use it about a year ago

As is sourcetree, and not tied to github

Plastic SCM is targeting Perforce users who want to go to a distributed model.