2 ms·

Git is great once you get how it works. It’s also a UX nightmare. I work with tons of artists and engineers from the games and film industry. Teaching git to

by dagmx 4y ago

Git is great once you get how it works. It’s also a UX nightmare. I work with tons of artists and engineers from the games and film industry. Teaching git to an artist is painful. UIs work, till they invariably fall apart and then they’re confused again in the command line. Also most UIs can’t abstract the ideas to a good easy system. Even a ton of very experienced engineers fall over when you touch rebasing etc… Now people will say use Perforce. Well that has its own issues around branching/streaming and integration for code etc… plus you’re tied to their systems, and I’m not convinced their UX is great either, just better. Plastic SCM seems to be the best so far but I haven’t really put it through the paces much. Anyway I guess my point is: git is a fantastic technology marred with bad UX. It’s much like GIMP or Blender back in the day that had terrible UX as well, but have since improved greatly. I’d love to see a rethink of the git UX at the UI level, that can guide even the most novice programmer through everything easily. 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.

miohtama 4y ago
Git is what a version control system would feel like if it were designed by kernel engineers who only knew C and Perl.
- JTBooth 4y ago
  The joke is that that's who is was actually designed by, right?
vijucat 4y ago
> Teaching git to an artist is painful Ouch. Just use TortoiseSVN (+ svn)? I've had good success with it with business users.
pronlover723 4y ago
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 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
- dagmx 4y ago
  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
  - pronlover723 4y ago
    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)
ilyt 4y ago
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

by dagmx 4y ago

miohtama 4y ago

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

JTBooth 4y ago
The joke is that that's who is was actually designed by, right?

vijucat 4y ago

> Teaching git to an artist is painful Ouch. Just use TortoiseSVN (+ svn)? I've had good success with it with business users.

pronlover723 4y ago

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 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

dagmx 4y ago
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
- pronlover723 4y ago
  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)

ilyt 4y ago

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