> The D is DVCS is a waste of effort.
until the de facto centralized remote goes offline and you’re stuck with no local history …
until the de facto centralized remote goes offline and you’re stuck with no local history …
There’s a reason we moved off centralized VCS en masse.
Distributed and “offline support” are fully orthogonal features.
Distributed means every user has a full copy of the entire repo including full history. This is a radical and unnecessary limitation on the scope and size of source control.
You can have full support for branching, commits, and merges without a fully distributed repo. There are numerous examples of this.
Then git must not be a DVCS; I use shallow clones all the time.
In any event, centralized systems probably can do offline support, at least in theory, but DVCSs more or less include it for free by default, which is still worth something.
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.
> 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.
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.
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.
Let me add to that: history and blame too.
You don't need the VCS to be a distributed VCS to have offline capability.
> There’s a reason we moved off centralized VCS en masse.
No, there's a reason we moved to git specifically. We didn't move to the competing DVCS, did we?
better than it used to, with the caveat that git in particular is not and has never claimed to be good at versioning blobs.