4 ms·

Sorry, but you’re completely and objectively wrong. This is a huge misnomer. Distributed and “offline support” are fully orthogonal features. Distributed mean

Sorry, but you’re completely and objectively wrong. This is a huge misnomer. 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.

yjftsjthsd-h 3y ago
> Distributed means every user has a full copy of the entire repo including full history. 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.
kstrauser 3y ago
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.
- puchatek 3y ago
  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.
  - deleted 3y ago
    [deleted]
- genocidicbunny 3y ago
  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.
  - maccard 3y ago
    Even not in games, moving away for months at a time with no coordination is a recipe for disaster.
  - kstrauser 3y ago
    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.
    - forrestthewoods 3y ago
      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.
ylyn 3y ago
You can't really have branches, commits and merges _while offline_ without a distributed repository. Let me add to that: history and blame too.

yjftsjthsd-h 3y ago

> Distributed means every user has a full copy of the entire repo including full history. 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.

kstrauser 3y ago

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.

puchatek 3y ago
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.
- deleted 3y ago
  [deleted]
genocidicbunny 3y ago
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.
- maccard 3y ago
  Even not in games, moving away for months at a time with no coordination is a recipe for disaster.
- kstrauser 3y ago
  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.
  - forrestthewoods 3y ago
    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.

ylyn 3y ago

You can't really have branches, commits and merges _while offline_ without a distributed repository. Let me add to that: history and blame too.