Large codebases that mix source code with binary assets have always been a poor fit for Git. Game studios, AI teams, and film pipelines dealing with multi-gigabyte textures, model weights, and raw video run into Git's object model repeatedly: slow clones, brittle Git LFS configurations, and no real multi-tenant access control. On June 17, 2026, Epic Games announced Lore at its State of Unreal 2026 keynote, an open-source VCS built from scratch to solve exactly this. This article is for developers and technical leads evaluating whether to adopt Lore for a project with large binary files or a large team. Lore is currently at v0.8.3, pre-1.0, so this is an evaluation, not a production recommendation.
Quick comparison: Lore vs Git at a glance
What is Lore?
Lore was formerly called Unreal Revision Control and was already the built-in version control system for UEFN (Unreal Editor for Fortnite), where creators used it to version their Fortnite islands. Epic open-sourced it at State of Unreal 2026 under the MIT license. The core library, server, and CLI are all written in Rust, with official SDKs for JavaScript, Python, C#, and Go. Everything routes through the same interface, so the CLI is not a special, privileged way of using Lore.
Structurally, Lore is two systems: a storage subsystem (a partition-based, content-addressed store that deduplicates all content while enforcing strict per-partition access boundaries) and a version control subsystem that builds revisions, branches, merges, and staging out of storage primitives. Every piece of content is stored once in an immutable store keyed by BLAKE3 hashes (a modern cryptographic hash function). Lore runs on Windows, macOS (ARM64), and Linux. The GitHub repository had 5.8k stars and 233 forks as of June 2026, which signals early interest but is not a maturity indicator.
How Lore handles large files differently from Git
Fragment-level deduplication vs Git pack compression
Git models content as complete objects and packs them with delta compression. This works well for text but poorly for large binary files because the delta between two versions of a 4 GB asset is not small, and the pack format was not designed for objects of that size. Git LFS sidesteps this entirely by replacing large files with text pointers stored externally. There is no deduplication across versions. If you update a 4 GB texture, you re-upload 4 GB.
Lore chunks all content and stores fragments independently. A 4 GB file that changes by 1 MB transfers 1 MB plus overhead, not 4 GB. According to Adam Sawicki's first look at Lore, this deduplication works even when data is inserted in the middle of a file, thanks to content-defined chunking using hashing. Identical fragments across branches or files are stored once.
Sparse by construction vs sparse as a workaround
Git's object model makes large repositories expensive to clone and to operate on. Workarounds like shallow clones, partial clones, and sparse-checkout address symptoms rather than the underlying design. Git's sparse-checkout is a post-hoc addition to a system where the working model is a full clone. Partial clone (introduced in Git 2.22+) also requires the user to be online and the origin remote to be available for on-demand fetching of missing objects.
Lore's sparse model is the default. A working copy is a window into a subset of the repository, and fetching a file is the normal case. The cost of an operation tracks the working set, not the repository. There is no giant initial clone for a project with terabytes of assets.
Binary-first vs text-first
Git's merge, diff, and history tooling is text-oriented. Binary files are second-class. Git LFS must be added manually via .gitattributes, there is no fragment deduplication, and the rest of Git's tooling cannot inspect binary content meaningfully. In Epic's system design documentation, the design goal is stated plainly: "All content is treated as opaque byte streams on the hot path. Text-aware features are layered on top, never assumed by the storage or transport paths. Binary content gets the same first-class treatment as text."
Centralization: the biggest philosophical difference
Git is a true peer-to-peer DVCS. Every clone is a full peer, can push/pull to any remote, and work fully offline indefinitely. This is powerful but constrains scale, since every client holds enough state to be a peer, which bounds how large a repository can grow and how partially any client can see it.
Lore is centralized by design. The remote is the single canonical source for which revision is latest, who can access what, and conflict resolution. There are no multiple remotes. This is the same model as Perforce, which is why large game studios use Perforce. Unlike Perforce, however, everyday operations (staging, committing, branching, and diffing) work fully offline. The server is only required for push and sync.
The practical implication for teams is real. As Sawicki notes in his first-look article, there are no multiple "remotes" to add to a local cloned repo. Support for forks is on the roadmap but not yet available. Teams that rely on multiple remotes, forks, or GitHub-style PR workflows will find this a significant change.
The staging model difference
Git's staging (index) stores an additional copy of file content. You can have three different versions of the same file simultaneously: the committed HEAD version, the staged version, and the working directory version. This confuses many developers, particularly those coming from non-text workflows.
In Lore, staging pins a path, not content. The commit captures whatever the file looks like at commit time. There is no separate copy of staged content. For teams working with large binary assets, this is more intuitive. You stage the file path, make edits, commit, and the commit takes the current state.
Access control and multi-tenancy
Git has no native multi-tenant isolation. Large studios manage this with separate repositories, server-side hooks, or external access tools, all bolted on after the fact.
Lore uses partitions as access boundaries. Knowing a content hash is not enough to fetch data. A user must also have access to the partition where it lives. This allows one Lore deployment to serve contractors with partial access, licensed IP assets that only legal-cleared teams can see, and separate team namespaces, all with strict isolation enforced at the server using the same underlying storage and deduplication. As Sawicki puts it, this is "useful for large studios with contractors, external partners, licensed IP, or assets that only some teams should see."
When to use Lore
Lore is likely a better fit than Git when:
- Your project mixes code with large binary files: game assets, 3D models, AI model weights, raw video, audio
- You have a large team where not everyone needs the full working tree (sparse working copies pay off at scale)
- You need partition-based access control for contractors, licensed IP, or per-team asset boundaries, without external tooling
- You want an open-source, MIT-licensed alternative to Perforce for binary-heavy projects (Perforce is proprietary and licenses by user count; Lore has no licensing constraint)
- You can tolerate pre-1.0 software with evolving APIs and have Rust-capable developers to contribute or debug
When to stick with Git
Git remains the better choice when:
- Your project is primarily text and code with few or no large binary files
- Your team relies on a decentralized workflow: multiple remotes, forks, GitHub or GitLab PRs, or offline-first branching
- You need production-stable tooling (Git is at v2.49.0 with a large tooling base; Lore is v0.8.3 with no stable API yet)
- Your CI/CD, code review, and developer tooling is tightly integrated with Git (GitHub Actions, GitLab CI, etc.)
- You need a VS Code extension or IDE integration today (both are on Lore's 2026 roadmap but not yet available)
- Your team has no experience with centralized VCS workflows (there is a learning curve even with familiar command names)
Production readiness: honest assessment
Lore is v0.8.3, pre-1.0. According to the official FAQ, APIs and protocols may still evolve before a 1.0 stable release. Data written into Lore is designed to remain readable by every future release, but interfaces are not stable.
The desktop client is available as a binary download but is not open source yet, as it currently depends on some proprietary components including Epic's internal design system. The open-source desktop client is on the 2027 roadmap.
Key gaps as of June 2026:
- No VS Code plugin (2026 roadmap, in progress)
- File locking informs but does not enforce (scalable locking on 2026 roadmap, in progress)
- No migration tooling from Git to Lore announced
- UEFN compatibility not yet complete (UEFN uses proprietary Oodle compression; open-source Lore uses Zstandard; migration in progress for 2026)
- No forks or isolated partitions yet (marked as "Later — exploring" on the roadmap)
- Virtual file system (VFS) not yet available; files are still materialized on disk (2026 roadmap)
Epic's stated goal for this phase is for "developers and technical leaders to explore Lore, prototype workflows on top of it, and help shape where it goes next." Use it for prototypes, internal tooling, non-critical projects, or evaluation, but not yet for mission-critical production repositories unless you can live with those gaps.
Try Lore in 10 minutes
If you want to evaluate Lore before committing to it, the quickstart runs entirely on your local machine with no account required.
Install Lore and start a local server
# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh | bash -s -- --demo
# Windows (PowerShell)
irm https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.ps1 | iex
The --demo flag starts a local server on port 41337 (QUIC/gRPC) and port 41339 (HTTP). No Docker, no Rust toolchain needed.
Create a repository and stage files
mkdir ~/my-project && cd ~/my-project
lore repository create lore://127.0.0.1:41337/my-project
echo "Hello, Lore" > hello.txt
lore stage hello.txt
lore status --scan
A .lore/ directory appears after repository create, which is where Lore keeps its local state.
Commit and push
lore commit "Initial revision"
lore push
The commit output shows fragment counts and bytes transferred rather than Git's object model output:
Fragmenting files and updating tree hashes
Committing staged changes
Committed 1/1 directories, 2/2 files, 269.00 bytes/269.00 bytes (2 modified, 0 deleted)
Repository: 3f2a1b4c5d6e7f8a...
Revision : 1
Signature : a3f8c2d1...
Branch : e7263180...
Date : Wed, 14 Jan 2026 09:24:18 +0000
Initial revision
Commit succeeded
The revision stays local until you push. Staging and committing work fully offline with no server round-trip needed.
Create a branch and merge
lore branch create my-first-branch
echo "Notes added on a branch." > notes.txt
lore stage notes.txt
lore commit "Add notes on a branch"
lore branch switch main
lore branch merge my-first-branch --message "Merge my-first-branch into main"
lore push
The command surface is close enough to Git that most developers can orient quickly. The key differences emerge when you start working with large files or multiple team members.
Command reference
One notable addition: Lore provides lore branch merge into <target>, which merges the current branch into a target branch without switching first. Git has no direct equivalent. To merge in Git, you must switch to the target branch first.
Conclusion
Lore solves a specific problem (large binary files at team scale) that Git handles poorly, and it makes no claim to replace Git for all projects. For game studios, AI teams, and film pipelines working with gigabytes of binary assets, Lore's fragment-level deduplication, sparse-by-construction model, and partition-based access control address real pain points that Git LFS cannot fully solve.
As Sawicki summarizes in his first-look article, Lore "looks promising" and "improves on many aspects that are important in game development," but whether it surpasses Git and Perforce in practice depends on whether it scales as promised and whether the GUI client and IDE extensions deliver. The honest caveat is that Lore is pre-1.0, the tooling support is thin, and most developer tooling still expects Git. Watch the roadmap, evaluate it now, and plan a migration when VFS and scalable locking land.