Hacker News Reader

I'd argue you're using the wrong tool for the job. Git isn't designed for art assets in games, it's design for text based source code. Everything else is an afterthought.

Games, especially AAA games, have 10s or 100s of terabytes of source assets. Git was never designed to handle this. git-lfs is a hack to try to help here but it's bolting on a workaround for a system that was never designed for managing art assets.

It's also not designed to handle the fact that generally art assets are not mergable and so it doesn't handle coordination of editing assets (making sure 2 artists don't edit the same asset at the same time)

No amount of UX is going to fix that git is the wrong tool for managing art assets.

update: Googling for gamedev asset management this came up

https://www.perforce.com/products/helix-dam

I have no idea if it's good or bad but hopefully it shows some ideas for how git is the wrong tool for art asset management

I’d agree if I was only working in games. But there’s lots of nuance.

Firstly, I’d already mentioned perforce.

But secondly , and this is my fault for not going into detail, I never said it was a game. There’s tons of software engineering categories with 3D art that are software heavy , so git wins out due to the ratio of engineers to artists.

Third, git with lfs configured from the get go isn’t that much worse than perforce with the exception of shallow and partial checkouts still being a pain. Otherwise perforce brings its own pains and UX hurdles. Streams and reviews for example are really rough to work with compared to git.

Lastly there’s just so much infrastructure around git. From hosting to CI/CD. Having multiple VCS is painful

Agree to disagree. Saying git exists therefore it should be used it like saying is all you have is a hammer everything is a nail. You wouldn't use a hammer for a screw and you shouldn't use git for art assets.

git-lfs only solves storage. It doesn't solve the 50 other things that are special about art assets.

Lastly there’s just so much infrastructure around git.

All that infra has nothing to do with art assets though. Again, looking at art as nail because all you have is a hammer (git)

You’re again misreading what I’m saying. At no point would anything I mentioned be described as only considering git as my only hammer.

It’s easy to say “you should use XYZ” in a vacuum but there are often always tons of other reasons to pick a solution.

Thanks for your thoughts, but they assume I’m not well versed in the domain enough to make the correct decisions for my teams.

It’s also besides the original point that git has a very poor UX. Like yeah there may be things with better UX, but that doesn’t lessen the original criticism nor does it mean one should switch just because of it.

Git is what a version control system would feel like if it were designed by kernel engineers who only knew C and Perl.

The joke is that that's who is was actually designed by, right?

Eh, just dust off graph theory and read Git Book like 3 times and you'll be fine /s.

But DVCS is just a bit of complex system to get. "Good UI" in this case is just finding enough common use cases and making them easy that the average mortal won't have to think what commands they type actually do. Case in point:

> Edit: also I know invariably someone will say to make my own Ui instead of complaining. I’ve tried. I’ve done some novel things but it’s really hard to do from a top down level without also rethinking some of the base interaction model. That’s a battle I think needs a lot of effort across the stack first.

as did many other. DVCS is a distributed system(doh) and those generally make reasoning hard for ones not used to thinking that way.

Aside from that I think git would benefit greatly if it had --explain command that would try to explain in human terms what the command you're trying to run actually does

> Teaching git to an artist is painful

Ouch. Just use TortoiseSVN (+ svn)? I've had good success with it with business users.