Epic Games released an open-source version control system — and it's not really aimed at Git

What Epic actually shipped

Lore is a version control system maintained by Epic Games and released under the MIT license, with the repository hosted — to the thread's amusement — on GitHub. Under the hood it looks Git-ish: content-addressed storage, Merkle trees, immutable revision chains, cryptographically verifiable history. The CLI is deliberately small, with a workflow that reads like Git with five verbs:

lore stage hello.txt
lore status --scan
lore commit "Initial revision"
lore push

Where it diverges is the data model. Lore is binary-first: chunked storage and deduplication for large files, branching without copying data, and sparse "hydration" — you fetch file data only when you need it rather than pulling the whole repo. It ships full-surface APIs across C/C++, C#, Rust, Go, Python, and JavaScript. The catch, which the thread caught immediately, is that all of this leans on a centralized, service-backed architecture with caching layers. It is not a distributed VCS in the Git sense.

The headline misses who this is for

The most useful comment in the thread reframed the entire story for the non-gamedev majority on Hacker News:

"This is not intended to compete with Git for general software development. This is a competitor with Perforce for game development. … one artist might need to obtain an exclusive lock on some art assets while editing them, because there is no sane way to merge two artists' async edits." — a commenter explaining the gamedev asset-locking problem

That lines up with where Epic has been operating. An engineer who has watched the space described the incumbent it's actually aiming at:

"They've been dabbling in this space within Unreal Engine for a few years. Perforce is the de facto standard in AAA studios from my experience, curious to see what's going to happen to them." — a graphics developer at speps.fr

The pain it targets isn't hypothetical even outside games. One reader keeps tens of gigabytes of PDFs in Git and called the experience exactly what Lore is built to fix: "git is really not well suited for this. No, Git LFS is not a solution."

"Not a DVCS in the traditional sense"

The architecture drew the most careful reading. One commenter pinned down the consequence of the central-server design:

"This does not seem like a DVCS in the traditional sense because it depends on coordinating with a central server where all repositories will be hosted. I can't tell if servers can pull/push from each other." — a commenter parsing the hydration model

From there the trust questions piled up. The docs, one reader noted, read like a machine wrote them:

"Their docs seem entirely LLM written. … they've left a lot of the unnecessary language and typical stylistic choices in there, which erodes my trust in the project a bit." — a commenter who read the FAQ closely

Another pointed at the launch site itself — laggy, broken text selection, a full CPU core spent rendering — and then at the deeper worry: handing your version history to a for-profit company. "I have absolutely zero trust in a product like version control being provided by a for-profit company," they wrote, "given their track record." The blunter version: "never trust epic."

A real Perforce alternative — if you're willing to trust Epic to host it

The enthusiasm is genuine where the pain is real: "It's great to finally see a possible alternative to Perforce," wrote one gamedev, and the asset-heavy crowd has wanted an open option for years. But Lore asks for something Git never did — that you accept a central server, run by Epic, as the place your history lives. For a studio already paying Perforce license fees, that trade may be obvious. For everyone treating this as "the new Git," it's the wrong frame entirely.