Edit: since this post is reaching people who do not know me, this started as a half-baked late-night Saturday thought. The main point I have made in the comments is that Git is fundamentally orthogonal to modern product development. It enforces unhealthy habits that you cannot fully escape, because they are baked into Git’s core functionality It's beyond me why brand new teams still pick git. Please. For the love of God. Stay away from Git. Not too long ago I realized I wasn’t built for the system when I noticed nobody questioned the stupid crap anymore. Not the tooling. Not the workflows. Not the assumptions baked into every "best practice" handbook written in 2012. The rise of vibe coding—new devs flooding in from outside CS—should be a renaissance. Vibe coders: the dev world is shackled to git. Worshipping a tool designed for patching the Linux kernel in 2005. This sub-par tool is actively holding the vast majority of companies back. Git got big because Linus built it. Everyone cargo-culted his name like it was gospel. Nobody asked if it was good. Nobody cared if it made sense outside Linux kernel development. Instead, you’re taught to memorize the rituals. - Smile through the pain. - Pretend it’s “powerful” when it’s just painful. Think git scales? Clone a 5GB repo with LFS. Watch your productivity disintegrate into timeouts and corrupted states. Modern workflows + Git = 40% of your time lost babysitting plumbing. Most recently, I was trapped inside a 70GB repo nightmare. Every developer had their own sacred list of Git rituals they swore were "the good ones," like medieval doctors prescribing bloodletting. Switching branches felt like spinning a loaded revolver — a 50% chance my internal storage would fill up and nuke my machine (And it did, more times than I can count.) There were moments — sitting there, screen frozen, fans screaming — where I wanted to rip my hair out and scream: "How does nobody else see this insanity? How are we pretending this is normal?" Sad reality: - They don't see it. - They never did. - They never will. Most of tech runs on inertia, not reason. If you’re coming in fresh—especially as a vibe coder—you have a shot at seeing the bullshit for what it is. Use it. That's why when we incorporated Torta Studios, I told Colin: "One condition. I call the tech shots. Veto power. No debates. First rule: git is banned for internal development." He agreed without hesitation. Because real companies aren’t built on cargo cults. They’re built on conscious engineering. Edit: I realize I didn’t suggest an alternative. Sapling is a nice hybrid between mercurial and git, it’s git-compatible, so you can still work with GitHub and all the usual git-based tooling, but the day-to-day feels a lot closer to Mercurial — simpler, safer, and more consistent. It’s been a refreshing change for me without having to abandon the broader ecosystem. | 651 comments on LinkedIn

they're putting large amounts of binary data in git lfs, which is what it was designed for. lfs does have some rough edges though. if I had something really heavy on binary blobs, ex a large game or similar, idk if I'd be using git either. he extrapolates way too far though, most use cases don't run into any of these problems

and storing all that in a separate db is insane, it's stuff that should be versioned with the code. it's likely being created at a specific rev for the current code, and it evolves with it. if you git revert or create a pr, it should be part of that. it's not like they committed built binaries or smth. there should be tools able to handle this. git could be one of them if lfs was less rough