Epic Games announced Lore, a new open-source version control system, at its State of Unreal 2026 keynote and released the project under the MIT license Lore launch report. The project’s GitHub repository describes Lore as “an open source version control system designed for unprecedented scalability of both data and teams” Epic Games / Lore. Whether it actually reaches that scale is not something the available record can confirm. What the record does confirm is that Git’s loose-object model becomes painful once history grows long or binary assets multiply, and that most engineering organizations have spent the last decade adding workarounds rather than switching tools.
Where does Git actually start to break?
Git is not slow simply because a checkout contains many megabytes; it is slow because its content-addressed storage model keeps every version of every file as a blob, and because it has no native way to diff, merge, or lock binary files. Released in 2005 under the GPL by Linus Torvalds to manage the Linux kernel, Git is a distributed version control system in which every clone is effectively a full server, as described in a 2024 Tencent News article by Dluck 独立游戏开发中的版本控制. That design is a feature for open-source kernel work and a liability for shops that accumulate years of commits or gigabytes of assets.
The distinction matters. A large repository can grow in two ways: excessive historical commits, or large binary files. The same article notes that game studios need version control that can manage massive binary files, including raw art assets, imported engine assets, and custom binary formats, and that Git’s model is poorly suited to the job 独立游戏开发中的版本控制. It stores each version whole, cannot produce useful diffs for formats such as images or compiled assets, and offers no file locking to stop two people from editing the same binary at once. The result is that repositories bloat, clones slow, and teams invent rituals such as “never commit the build output” that do not solve the underlying graph explosion.
Git LFS mitigates this by handling large binary files through an add-on rather than as a built-in part of Git Lore launch report. That is the shape of the compromise.
What are the usual workarounds?
The standard response to Git’s binary and history bloat is not to replace Git but to bolt on mitigations that keep the core tool in place. Git LFS is the most common. It moves large files out of the repository graph so clones stay smaller, though it does not make binary handling a built-in Git capability Lore launch report. The trade-off is a smaller clone, not a different model.
For large game studios, the mitigation is usually more radical. As of 2024, Perforce is widely used in game development and large-scale enterprise projects because it handles large user and file counts well, especially where massive binary assets are involved 独立游戏开发中的版本控制. The workaround is not elegant, but it reflects a hardened operational fact: Git’s sweet spot is text, not everything else.
Shallow clones and submodules are the other common patches. A shallow clone trims history; submodules let a team partition a monolith into smaller repositories. Both introduce their own failure modes. Shallow clones break commands that expect full ancestry; submodules turn every cross-repo update into a small coordination ceremony. Each workaround is an admission that Git’s default model is being stretched past its design intent.
| Approach | Handles large binaries | Distributed model | Where it fits |
|---|---|---|---|
| Git alone | No | Yes | Text source, modest history |
| Git + LFS | Partial, via side store | Yes | Mixed assets, small-to-mid teams |
| Perforce | Yes | Centralized | Game studios, massive binary assets |
| Shallow clones / submodules | Partial | Yes | Partitioned repos, CI-only clones |
What would a new version control system have to prove?
Before any replacement can justify a migration, it has to beat Git on dimensions that are measured in production, not on a landing page. The most important dimension is verifiable performance on the exact workload that hurts the team: cloning a multi-gigabyte repository, checking out a branch with large binaries, running garbage collection, resolving a merge across long histories, and running git blame on files with thousands of revisions. Claims of scalability mean almost nothing without a reproducible benchmark on a realistic repository.
The second dimension is the migration path. A VCS that cannot import Git history, preserve authorship and timestamps, and coexist with existing CI pipelines is a non-starter for most organizations. The cost of losing blame history or rewriting every build script exceeds the cost of a slower clone for all but the most desperate teams. Migration tooling therefore matters as much as raw speed.
The third dimension is licensing and governance. Git is GPL and has decades of legal review. Any new open-source entrant must be clear about its license, contributor agreements, and whether it is backed by a foundation or a single vendor. “Open source” is not a single condition; it is a bundle of conditions that procurement, security, and legal teams will check independently.
Lore is positioned as an open-source alternative aimed at the scalability ceiling where Git’s model strains. The repository describes its goal as “unprecedented scalability of both data and teams” Epic Games / Lore, and the launch report notes that Epic built it in-house before releasing it for free Lore launch report. The project would still need to publish benchmarks, migration tooling, and production adoption reports before it can be evaluated as a serious replacement.
What does it cost to leave Git behind?
Even a technically superior VCS faces a tax that has nothing to do with graph algorithms. The first bill is tooling. Most organizations have built their workflows around Git’s object model and command vocabulary, from CI integrations and hosting providers to IDE plugins and command-line aliases. Replacing Git means either retraining those tools or maintaining a compatibility shim that adds latency and bugs.
The second bill is operational expertise. A generation of engineers has learned git rebase -i, git bisect, and the difference between git reset --soft and --hard. That knowledge is not trivially portable. A new tool would have to be dramatically better to offset the hiring, training, and incident-response friction of a smaller community and a shallower archive of solved problems.
The third bill is risk. Git has been stress-tested by the Linux kernel, every major cloud provider, and millions of repositories. Its failure modes are documented, its recovery rituals are known, and its maintainers have a long track record. A new system, however promising, cannot buy that history with venture funding or a clever data structure.
Why name a version control system ‘Lore’?
Merriam-Webster defines “lore” as “a particular body of knowledge or tradition” Definition of LORE, Merriam-Webster. A wikiHow explainer on the slang usage notes that “lore” traditionally refers to background information on a fictional entity or universe, and has more recently evolved to mean the stories that define a person’s identity TikTok Slang Explained: What Does ‘Lore’ Mean?, wikiHow.
Cambridge corpus usage reinforces the connotation: “clinical lore,” “runic lore,” “marketing lore” lore, Cambridge Dictionary. In each case the word signals knowledge that is received, semi-formal, and shaped by practice rather than by specification. That is an apt description of how most teams actually run Git. The formal model is in the manual; the real model is the accumulated folklore of which commands to avoid, which hooks to install, and which repositories need LFS.
If Lore the project succeeds, the name is a sly acknowledgement that every VCS eventually becomes a tradition as much as a tool.
Should operators switch?
Lore is no longer a rumor: Epic has shipped the repository and announced the project. But it is still a promise to fix a verified problem. Until the project publishes reproducible benchmarks, migration tooling, and production adoption reports, operators should treat it as a signal to audit their own Git pain points, not as a reason to schedule a migration.
The right immediate action is to measure what actually hurts: clone times, checkout times, LFS transfer costs, binary merge conflicts, and CI latency. Fix the workflows that are slow. Keep an eye on new entrants. And require any replacement to demonstrate its advantages on your repository, with your history, and your CI load, before it gets past a pilot.
Frequently Asked Questions
Does Lore matter for teams that are not running monorepos?
Lore targets the point where Git’s loose-object model chokes on long history or binary assets, not just giant monorepos. One developer’s self-hosted GitLab plus Git LFS setup for an Unreal Engine 5.2 source project, with a roughly 1.5 GB engine repository and about 50 GB of third-party dependencies, already hit that threshold. Teams with similar mixed-asset workflows can feel the same pain well before they reach Fortune 500 repository sizes.
How is Lore’s licensing different from Git’s?
Git is released under the GPL, which carries copyleft obligations and decades of accumulated legal review inside large organizations. Lore is released under the MIT license, which is more permissive for commercial embedding and modification but has not built the same procurement familiarity. For legal and security reviewers, that distinction can matter as much as performance numbers.
What is the hardest migration problem Lore will face for existing Git repositories?
Importing history while preserving authorship, timestamps, and branch topology is already difficult, but the harder problem is repositories that already use Git LFS. Those repositories store pointer files in the Git graph while the real blobs live in a side store. A migration tool must translate those pointers into Lore’s storage model, or the new repository will silently re-bloat and defeat the reason for switching.
Why might Lore’s benchmarks not translate to a real advantage for my team?
Benchmarks usually run on clean, synthetic repositories with simple branch shapes, while real teams have years of merge commits, renamed files, and LFS side stores. A tool can win on raw clone speed and still lose on the commands your team runs daily: interactive rebase, bisect, blame on files with thousands of revisions, and cross-platform line-ending behavior. Those are the workflows that actually consume engineer hours.
Could Lore’s release actually help Git more than it hurts it?
Competition from a well-funded project can pressure Git maintainers and hosting platforms to improve binary handling, partial clones, and performance tooling. That has happened before in adjacent markets: a visible competitor often accelerates investment in the incumbent. If Lore’s benchmarks are credible, Git’s ecosystem may absorb the pressure by shipping better mitigations, which would reduce the incentive to migrate for teams that are only moderately stretched.