Git's Plan for the Next Decade: SHA-256, Faster Clones, and Maybe Handling Your 50GB Model Files
The Git maintainers gave a talk at FOSDEM 2026 about where Git is headed, and ngl, it's a refreshingly honest look at the technical debt of the world's most successful version control system.
The SHA-1 Situation
Let's address the elephant in the room: Git is still using SHA-1 in 2026. When Git launched in 2005, Linus Torvalds considered SHA-1 secure. Plot twist: crypto experts had already found collision attacks and were recommending SHA-2. Classic Linus dismissing concerns with his usual "I know better" energy.
The argument was always "we're not using it for security," which... sure, but then why not use CRC-128? Would've been faster, and enterprises wouldn't be demanding its removal by 2030. The SHA-256 migration is happening, just very slowly, because turns out rewriting Git's fundamental assumptions is hard.
What's Actually Shipping
Partial Clones: This is lowkey the most practical feature they're working on. Clone repos without downloading every blob immediately. Game changer for monorepos and teams that can't wait 20 minutes for git clone to finish.
Better Large File Handling: Finally. Game devs and ML engineers have been hacking around Git's limitations forever. Hugging Face had to build git-xet just to version models without their repos becoming unusable. The solution everyone agrees on? Content-defined chunking. It works for git-xet, it works for other VCS systems, and Git might actually adopt it.
Object Database Refactor: They've unified the ODB interface, which sounds boring but actually means plugins like git-xet could become first-class citizens. This could be huge for teams dealing with binary assets.
The Security Theater
Here's the thing about sneaking malicious commits past Git's SHA-1: it doesn't really work in practice. Email workflows involve explicit patch review. Remote workflows have protected branches and CI checks. You'd need force-push access to master, which... no one has in a properly configured repo.
The Jia Tan-style attack (sneak in a benign commit, replace it later with malicious code) is theoretically possible, but requires bypassing so many other security layers that the hash function is probably your least concern.
What This Means for You
If you're shipping web apps, most of this is background noise. Your repos are fine.
If you're in ML/AI or game dev and wrestling with large files, the upcoming chunking support could actually fix your workflow. No more git-lfs hacks or separate asset management systems.
If you're maintaining OSS projects, the partial clone improvements mean contributors can actually clone your 10GB repo without giving up and going for coffee.
The Real Take
Git is 21 years old. It's evolving like any mature project: carefully, with an eye on backward compatibility, prioritizing practical improvements over flashy rewrites. The SHA-256 migration will eventually happen. Large file handling will get better. The ecosystem will adapt.
Is it moving as fast as a greenfield VCS written in Rust with algebraic effects? No. But it's Git—it runs on 100 million+ repos and can't afford to break things. Sometimes boring reliability is based.
The comments section is already debating whether SHA-1 was ever truly secure (it wasn't), whether Linus was too cocky (he was), and whether Git should've just used CRC-128 from the start (probably). But here we are, shipping incremental improvements to software that powers literally all of modern development.
That's the vibe.