Comment by kstrauser | Hacker News Reader

Comment by kstrauser | Hacker News Reader

Parent Full thread

That's an interesting, and wrong, definition of "wrong".

Git, Mercurial, and the like make every full copy of the repo equal. By convention, we often use central repos like GitHub, and commands like "git fetch" and "git push" as fast ways to sync their contents. We don't have to, though.

I can clone a remote repo, then work independently for months. I do this all the time with the Mastodon server I run. I periodically pull in upstream changes, merge them into my working copy, then push those changes out to my worker instances. I might SSH into one of those servers, fix something specific to it, push the changes out to the other local servers so that they're all synced, and repeat for weeks and months on end.

And because each of those repos are equally "official", all branching and merging operations are equally easy on each one of the peer machines. Although it's conceptually possible that it could be just as easy on a VCS that doesn't work with full clones, I've never seen it.

It seems you're still largely talking about mostly text files. The parent you're replying to works in video games, where 99% of the data stored in VCS by volume (if it's even stored in VCS) is not text data. It is things like textures, audio files, processed geometry..etc. It is extremely easy to have one single texture take up more disk space than the entire source code for the game.

> I can clone a remote repo, then work independently for months.

If you're working with more than 0 other people in video games, good frakking luck doing this. If you're working on a large enough game, you're also going to need potentially multiple TB of storage just to have a full shallow copy of the repo (with just the latest copies.) I have worked at a studio where a full deep clone of the repo for just one game was well over 100TB. Let's see you load that up on your laptop.

Even not in games, moving away for months at a time with no coordination is a recipe for disaster.

The don’t use Git for it. Emacs is a crappy Photoshop replacement, but it’s great at it was actually built for. Git isn’t great for video game assets, but it’s great at what it was actually built for.

Use the right tool for the job. The parent poster is complaining that their employer picked the wrong tool for their job, then insisting that the tool sucks.

You’re missing the point.

Git is optimized for a specific use case. This prohibits other use cases. I think Git could be slightly tweaked to optimize for and enable different use cases. I think far more users would benefit from the new use cases than the old.

I want to use the right tool for the job. I wish Git were changed slightly so that it could be the right tool.

Git is not capable of handling video game assets. It could be. I wish it were. You may may be happy as is. I think you would actually be happier if my use case were supported. Because I think Git is over optimized for an ultra niche case that doesn’t matter to most users. And yes I realize most users are not game developers.

Git is great at what it was built for. Almost all current Git users do have the same requirements as the thing Git was built for. Therefore Git is a sub-optimal tool for almost all users. The world deserves an optimal tool. The hegemony of Git and GitHub makes it difficult for an optimal tool to be made and therefore all users suffer.

Interesting usecase. The "git bad for everything else" commenter was probably unaware of it. That said, it's not very representative of what git is mostly used for and where there comparison with fossil is least favorable.

Reply on news.ycombinator.com