[genocidicbunny]

Now explain this to an artist with very little programming experience beyond what they picked up from their coworkers.

I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them.

I worked in gamedev, and many of my colleagues were brilliant, but your comment would read as complete nonsense to many of them. That is the problem git has in the gamedev space. You're trying to manage teams of programmers, designers, sound engineers, gameplay specialists, producers...even c-levels. The parent comment to yours is right, to many many people who work on things that Lore could be useful for would find git to be gobblygook.

[js2]

I'm not here to engage in rhetorical combat.

I was simply answering niek_pas's rhetorical questions, that's all, because maybe they piqued someone's curiosity and I can contribute a little of my esoteric knowledge about the inner workings of git. This is a site for the curious, yes?

Git is a tool by programmers for programmers. If folks outside the programming community are able to use it, great, but that's not its target audience. You don't need to convince me why git isn't suitable for artists.

Cheers.

[genocidicbunny]

I apologize if I came off harsh and combative. Gamedev is a passion for me and I spent many years in that field, including working on proprietary version control systems because existing ones like SVN, Git, Perforce...etc did not fit the needs of the team.

One of the things I very frequently heard from the non-programmer disciplines was how obtuse and indecipherable the existing version control systems were. That is where I'm coming from.

Your knowledge is still appreciated, by me as well, because while I am well familiar with the way git works, I have worked with many people who were not, and did not have the time or budget in their minds for understanding it because they had many other concerns. That is what I mean when I said that I worked with some brilliant people -- I could not do even a modicum of what some of them were capable, and likewise they probably weren't capable of the same modicum of what I was doing.

I don't know what specifically the GP post was trying to insinuate, if anything at all, but it resonated with me as someone who had experienced the same thing many times over in my career. And I probably judged your comment a little harshly on first read, which is mea culpa. You provided good information for those newer to git and seeking to understand how it actually works besides the cheat sheet guides you so often find.

> Git is a tool by programmers for programmers. If folks outside the programming community are able to use it, great, but that's not its target audience. You don't need to convince me why git isn't suitable for artists.

Precisely, and I think Lore is an interesting proposition for exactly that reason.

[jen20]

> I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them.

Git is a software development tool first and foremost to support the development of an _operating system kernel_. It's perfectly reasonable for it to be technically verbose as a default, in the same way as it's reasonable for a band saw to cut off your finger if you use it without understanding things correctly first.

The problem git has in game development is not that the output is too complex, it's that it doesn't handle large binaries well (ironically enough, the focus of the replacement system in TFA).

[genocidicbunny]

While I agree that git is a tool for the development of an operating system kernel, it's become clear that this is not the general perception of it. I don't mean those of us who have followed it throughout it's evolution, but those that are not 'in the know'. I have heard probably too many programmers pushing it as the end-all-be-all solution for version control even in environments not appropriate for it.

I will disagree that the output is too complex; it is. And yes, the large binaries issue is also a huge challenge to it's use. There's only so much time in the day, and when you work in gamedev there are often severe pressures to perform, and spending extra time to get into the weeds of a version control system is often not possible without sacrifice.

[jen20]

> but those that are not 'in the know'.

Those are not the target market, and that is OK.

> spending extra time to get into the weeds of a version control system is often not possible without sacrifice.

Which is why most Gamedev places use perforce and not git. Or, perhaps now, Lore.

[1718627440]

It's a progress indicator. Everyone has had the concept of percent in school even if they are an artist.

[genocidicbunny]

No, it's mostly nonsense to them.

You know what's a progress indicator? An actual progress indicator. Not some text telling you such and such process is 1234/5678 steps done...followed by yet another line of text telling you that the process is now at step 3 of 20. It could just be a % indicator with a spinning cursor, unless the -v/-verbose flag is present.

Of course artists can learn to understand what all this means; But that is not their job, they have other things to deal with besides the esoteric and overly verbose CLIs we programmers often make.

[wtetzner]

Do you really think that the `git push` output matters in one way or the other to artists?

I feel like the blocker is understanding how to use git, not the output of `git push`. It just feels like a bad example.

[qwery]

git is not a particularly suitable VCS for gamedev for reasons so much deeper than what messages it prints for a given command. git is a tool built to solve versioning text files in a collaborative, open software development context. That is the problem git has in the gamedev space.

[mariusor]

Your straw man artist should use any of the nice frontends that work on top of git and hide its verbosity.

[dijit]

Yes, then it breaks because you gave your artist an SSH link to clone and LFS requires a HTTPS auth token and exits with terse errors.

Or, you need to lock your files and git doesn't really support that.

To be fair, your hypothetical is true: UE5 supports Git as a backend, you don't need to run git commands (most of the time), but in practice even in the best circumstances: Git for game dev is brittle, slow, and extremely space inefficient.

Worse still: people try pushing their "short lived branches" workflow when using Git, which is *not* how gamedev works, especially for artists. Longer lived changesets are more common. (in Perforce these are called Shelves).

[wtetzner]

What do you mean about the short lived branches? Long lived branches work just as well in git as anywhere else (and it's easy to keep them mergeable by keep master merged into your branch).

[mariusor]

> Git for game dev is brittle,

You're basically reinforcing my point which was that the artist argument is a straw man, and companies that need artists to interact with version control will most likely use something else than git.

[genocidicbunny]

> artist should use any of the nice frontends that work on top of git and hide its verbosity.

Right up until something goes fucky. You know how many times I got messaged by someone dealing with vcs going wrong for them at a late hour in the evening? If I had a nickel for every time, I wouldn't be rich, but it probably would have bought me a gallon of gas.

It's not the verbosity strictly speaking. It is the minimal level of abstraction between you and the vcs and it can hardly be helped by a 'nice frontend' when things go wrong. And they will; they always do.

[wtetzner]

> It is the minimal level of abstraction between you and the vcs and it can hardly be helped by a 'nice frontend' when things go wrong. And they will; they always do.

How is this different from any other piece of software ever? When things go wrong, the artist is stuck either way. The only solution is software that always works...

[feelamee]

I don't understand - you arguing that artists should learn to use cli? if so, "programmish" git output is not a problem, because they already not just artist, they learned git.

But, for me this looks like this - if artist need to go to cli to solve some error, then this is bug or leaky abstraction in GUI client.