[nightfader]

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 route it's in a teams or projects best interest by keeping the repo size small so new clone by newly onboarded devs or during a CI pipeline don't take forever. Fossil is an all in one VCS with wiki, issues etc which I don't appreciate because for one it's not feature rich and for another it bloats the backups and restores. So I prefer gits Unix philosophy of doing one thing but doing it really well. There are some philosophical amd usability differences between fossil and git too but in the grand scheme of things it doesn't matter when one has been using git for a long time. Fossil doesn't have an ecosystem either and making it work with CI CD is a pain because CD tools like agrocd or flux or CI tools like gitlab/gitbub/circle/travis CI systems don't work with fossil out of the box.

[maccard]

> The whole point that git rejects large blobs is primarily because they don't belong in VCS.

Who are you to say that my blobs don't belong in version control? Where does a versioned asset file for a website or a game go, if not in version control? If the answer is "somewhere else referneced by the git commit", then you're accepting that the data belongs in version control but that git can't handle it.

> But for those who need large blobs there is git-lfs as the author mentioned.

git-lfs isn't git, though. It's a bodge on top of git that breaks many of the assumptions about git, requires special handling and setup. If it _were_ a core part of git I would agree, but it's not.

> So I prefer gits Unix philosophy of doing one thing but doing it really well

Git is tightly coupled to a _bunch_ of unix tools, and doesn't work without them. Try running git on windows and see that installs an entire suite of posix tools (msys) just to let you run `git clone`.

[IshKebab]

People only think large blobs don't belong in VCS because they don't work well with Git.

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.