41–50 of 197 posts
Earlier quoted context omitted.
Not in gamedev where you can have hundreds of gigs of art assets (models, textures, audio...), but you still want to version them or even have people working on them at the same time (maps...). But that is a different can of worms entirely.
That's what object storage with versioning turned on is for e.g. GCS or S3
I love git and I find no reason to look for anything else. Most of the complains I hear from git is from people that could not learn its logic. I think a lot of things could be built on top of git.
See most of the points labelled with links to 2.5 plus the comment about showing what you actually did I no rewriting and lying about history, tyhe errors you made are often just as important as the correct way of doing things.
I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab. Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of no…
It is extremely rare that I have a file over 100MB. I also think it’s one of those situations where if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better. It’s like in the olden days when you couldn’t put blobs directly in a row so databases made you do your file management yourself instead of just plopping in files. I like git. I don’t like giant binary files in my commit…
I store binary files outside of git but keep build logs containing binary file CRCs on git
Earlier quoted context omitted.
if you have large files in your repository, you have a design problem.
Not in gamedev where you can have hundreds of gigs of art assets (models, textures, audio...), but you still want to version them or even have people working on them at the same time (maps...). But that is a different can of worms entirely.
In your scenario, you just want to track different versions of a file.
Earlier quoted context omitted.
Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box. I’ve not used fossil, but I appreciate this idea. Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though the…
> Well, do you use GitHub or an equivalent? Not sure how that's relevant, but I have ~150 repos locally and less than 10 on github. I also like the unix philosophy of having tools that do one thing and do it well.
The whole point that git rejects large blobs is primarily because they don't belong in VCS. But for those who need large blobs there is git-lfs as the author mentioned. I don't see a problem with that approach because I personally don't like my git repos growing large after just a few commits which then takes up time for huge clones by other devs. This is the whole principle behind monorepos. If going the monorepo ro…
As soon as a VCS comes along that actually handles that properly people will say "of course, it was obvious that it should have been like this all along!".
Git LFS is a proof of concept, not a real solution.
Unfortunately none of the new Git alternatives I've seen (Jujitsu, Pijul etc) are tackling the real pain points of Git:
* Submodule support is incomplete, buggy and unintuitive
* No way to store large files that actually integrates properly with Git.
* Poor support for very large monorepos where you only want to clone part of it.
In a way, Git is bad at everything that centralised VCS systems are good at, which isn't surprising given that it's decentralised. The problem is that most people actually use it as a centralised VCS and want those features.
Lots of people are saying that having large files in a repo is wrong, bad, bad design, incorrect usage. Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that? The major issue with big files is resources: storage, and network bandwi…
How is it not bad design? Let's say you are working in a team. Would you really want your colleagues spending a significant amount of time cloning your artifacts? Your comment is also not consistent with forgetting that one is not a developer. Even if it's my grandma, she's not gonna want to wait for 1hour to download a giant file from VC assuming she knows what a VC is. Large blobs can go into versioned object stora…
Some projects need the ability to version big files, there is a good reason why perforce exists and is widely used in the gaming industry.
Earlier quoted context omitted.
That's what object storage with versioning turned on is for e.g. GCS or S3
Why use git at all then? Just use an object store with versioning turned on.
Earlier quoted context omitted.
Not in gamedev where you can have hundreds of gigs of art assets (models, textures, audio...), but you still want to version them or even have people working on them at the same time (maps...). But that is a different can of worms entirely.
That's what object storage with versioning turned on is for e.g. GCS or S3