Hacker News Reader

Comment by flohofwoe | Hacker News Reader

I think what's often overlooked is that git wasn't created as a general solution to version control, but for the specific needs of Linux kernel development.

Game development is pretty much on the opposite end of the spectrum, 99.9% of game project data isn't text (maybe not by number of files, but definitely by file size), and game development also traditionally isn't as extremely decentralized as Linux kernel development.

The problem isn't git, but that it has become so popular that it's now the defacto standard version control system, and people expect it to work for scenarios it wasn't created for (at least people who don't know much about the specific workflow requirements of large-scale game development).

View on HN

> git wasn't created as a general solution to version control, but for the specific needs of Linux kernel development.

This is an instance of a more general problem in all software development: tools are created usually to serve a purpose, but when they become popular they end up being used, not because they're a good fit for the problem, but because they're popular -- everybody knows how to use them. The tradeoff (which may be worth making) is the time to learn a new tool vs. the continual cost of using a tool that's not quite right for what you're doing.

Specifically the thing that Git was meant for was there being multiple authoritative roots. In the sense that RedHat can keep their own kernel line and just bring in patches from Linus and other maintainers as well. Everyone can be authoritative! This is great for example if you need to fork a library to make some changes (eg replace a library it's using in it's implementation) but want to keep current with it's improvements.

...this is not the case for most projects. They want to have a clear source of truth for the code.

I'm not sure that is overlooked. It is just not especially relevant for a modern world where the huge majority of versioned development at centralized organizations is done with git.

Almost none of these thinkpieces about git are saying that Linus was foolish in his approach or that he should have anticipated git becoming the lingua franca for junior engineers at megacorps. Instead almost all of them are talking about git's failing in modern development and bemoaning the lack of a better option, followed by a bunch of people insisting that git is actually awesome as long as you can reason about graphs.

I think your criticism here is actually implicitly already part of almost every discussion about git in modern times.

It's not a criticism really, just an observation ;)

It just happens so that most software development is more like the Linux kernel and less like game development, so for most software projects git is a good fit indeed, just not for gamedev. Maybe it's worth looking into how CGI studios are managing their data, I guess they have the same problems to solve as gamedev studios.

There are specialized solutions though, like https://www.plasticscm.com/ (quite recently acquired by Unity).

> It just happens so that most software development is more like the Linux kernel and less like game development

I don't think that is true. Linux kernel development is truly distributed. It is expected that there are multiple completely deployed branches. Most software development using git does have a single point of ownership and a single release branch. It is done on company machines with managed environments.

Reply on news.ycombinator.com