Epic's Lore: the open-source version control built for the repos Git and Perforce choke on

Epic Games just open-sourced Lore, a version control system built to do the one thing Git was never good at. It’s a centralized, content-addressed VCS designed for repositories that mix source code with multi-gigabyte binary assets, the daily reality of any game studio.

That focus is the whole story. Lore landed at the top of Hacker News with 1,099 points and nearly 600 comments, which tells you the pain it targets is widely felt. Git handles binaries badly, Perforce charges for the privilege of handling them well, and Git LFS is the duct tape most teams resent. Lore is Epic’s attempt to fold all three problems into one tool, released under the MIT license so anyone can run it, fork it, or build on top. The version on GitHub is the same engine that powers version control inside Unreal Editor for Fortnite, now handed to the rest of the industry.

What Lore actually is

Lore represents a repository as a Merkle tree with an immutable revision chain. In plain terms, every file and every version is identified by a hash of its contents, and the history is tamper-evident: you can verify that a revision is what it claims to be. That part will feel familiar to anyone who’s used Git under the hood.

The difference is what happens with big files. Lore stores files as chunks with an indexed lookup, so two assets that share data store that data once. Edit a few kilobytes inside a 4 GB level file and Lore re-uploads only the changed chunks, not the whole thing. Workspaces stay light because data is fetched on demand. You pull what you touch, not the entire 200 GB project, and branches are cheap because switching them doesn’t duplicate data.

It’s centralized by design, and that’s a deliberate split from Git’s distributed model. There’s a server of record for durability, access control, and conflict resolution, which is what asset-heavy teams want. But normal editing, staging, committing, branching, diffing, never needs a network round trip, per the project FAQ. That hybrid is the core of the pitch: a central authority where you actually need one, with local speed everywhere else.

Why Git and Perforce both fall short

Game repos break the assumptions Git is built on. Git’s revision graph is genuinely good, and Epic says so plainly. Its docs call that graph “excellent,” then land the criticism: Git makes binary files second-class citizens. A 3D model or an audio file isn’t diffable text. Git stores a fresh copy on every change, the repo balloons, and clones crawl. One developer on Hacker News put the everyday version bluntly: “Git is fine for text based files like code, but it’s really bad at stuff like textures, 3D models, audio files.”

There’s a second Git gap that game and film studios hit early: access control. Git is all-or-nothing on a repo. You can’t fence off a directory of unreleased assets to only the people who’ve signed an NDA. A commenter in the thread flagged exactly that, noting you can restrict directories “for only those who have signed the required NDAs. That’s not something that you can do in git: it’s all or nothing.” Lore’s centralized server-of-record exists partly to make that kind of per-path permission possible, which is table stakes for a studio with contractors and partners touching the same repo.

Git LFS was supposed to fix this, and mostly didn’t. It parks binaries on a side server behind pointer files, but there’s no clean way to drop old history, so years of iterated early assets sit in storage forever. Commenters called it “unworkably clunky.” On a paid GitHub tier, that dead weight costs real money every month.

Perforce is the incumbent that handles binaries well, which is why most large studios pay for it. The cost is centralization and speed. Standard operations require server round trips, the wire protocol is proprietary so nobody can write a compatible client, and deduplication at the binary level is limited. A tools engineer in the thread described reconciliation jobs that “can take hours, potentially days” on large codebases and sometimes never finish. Lore’s answer is fragment-level dedup that works as well on a multi-gigabyte binary as on a kilobyte of text, plus an open, documented surface anyone can implement against.

Who’s building on it already

The MIT license is the part that changes the math. A studio that adopts Perforce is renting a closed system. A studio that adopts Lore owns its stack, can self-host with no licensing fees, and can wire it into whatever tooling it likes. Epic ships SDKs for JavaScript, Python, C#, and Go, with full-surface APIs spanning C, C++, Rust, and more, so the CLI isn’t the only way in.

Third parties moved fast. Anchorpoint, a desktop client popular with art teams who don’t live in a terminal, announced Anchorpoint for Lore the same week, giving non-engineers a visual front end. That matters more than it sounds. Lore is explicitly built for “developers and artists alike,” and artists don’t want a command line.

One honest caveat on parity. The open-source build uses a different compression format than the proprietary one inside Unreal Editor for Fortnite. Epic says it’s actively moving the Fortnite editor onto the open format, so the two converge over time, but they aren’t identical today. There’s a reference cloud deployment on AWS S3 and DynamoDB, though Epic frames the storage backend as replaceable rather than a hard dependency.

The proof point worth weighing is who already runs this engine. Lore began life as Unreal Revision Control, Epic’s internal system, and it’s the version control baked into Unreal Editor for Fortnite, a tool used by tens of thousands of creators publishing islands inside Fortnite. That’s not a lab demo. The code Epic just put on GitHub has been carrying production game-asset traffic, which is a different level of confidence than a brand-new project asking you to trust it. The open release is Epic taking something battle-tested and removing the reasons a competitor couldn’t adopt it.

What this means for you

If you ship a game, or anything where code and gigabytes of media live in one monorepo, Lore is worth a real pilot. Stand it up locally, push a fat asset directory, and time a branch switch against your current Perforce or Git LFS setup. Then re-save a small tweak inside your biggest asset and watch how much actually uploads. If only the changed chunks go over the wire, that’s the dedup working, and it’s the number that justifies a migration. For a normal web or backend repo, skip it. Git is still the right tool, and Lore isn’t trying to take that ground.

The thing to watch is the version number. Lore is pre-1.0, Epic warns the on-disk format can still change, and a format change mid-project is not a small inconvenience for a 200 GB repo. My read: prototype on it now, keep your production history somewhere stable, and revisit a full migration once the format locks and the Fortnite editor has fully moved over. The Hacker News reaction wasn’t hype. It was a lot of people who’ve fought Perforce for a decade finally seeing an open exit.