HN Debrief

Lore – Open source version control system designed for scalability

  • Developer Tools
  • Open Source
  • Gaming
  • Infrastructure

Lore is Epic’s newly open sourced version control system for asset-heavy development. It is centralized by design, not a distributed Git clone, and it targets the problems common in game production: terabyte-scale repos, non-mergeable binary assets, file locking, sparse or on-demand workspaces, and finer-grained permissions than a whole-repo boundary. Epic says it grew out of Unreal Revision Control used in Unreal Editor for Fortnite and is moving into broader internal use, which made people take it more seriously than a greenfield side project.

If you build software around large binary assets, file locking, or partial workspaces, Git plus add-ons is still a poor fit and the market is open. Lore is worth tracking less as a Git replacement and more as a sign that Epic may try to reshape the Unreal and game tooling stack around an open Perforce competitor.

Discussion mood

Mostly excited but cautious. People who have lived with Perforce or Git LFS were enthusiastic about a real alternative, while the main negatives were distrust of Epic, weak confidence in the docs and polish, and doubt that a new VCS can overcome ecosystem and workflow lock-in.

Key insights

  1. 01

    Chunking and hydration are the real differentiators

    Lore’s pitch gets stronger once you look past “Git but for binaries.” The key difference is chunked binary storage plus on-demand hydration, so changing a huge file does not mean redownloading the whole thing and users can materialize only the assets they actually need. That is a much more practical model for game teams than Git LFS pointers, especially when a single workspace can reach hundreds of gigabytes or more.

    When you evaluate systems in this space, focus on transfer behavior and workspace hydration, not just whether they can store large files. The cost driver in daily use is how much data moves for small edits and how much disk every role needs locally.

      Attribution:
    • regnerba #1 #2
    • danudey #1
  2. 02

    Unreal integration may matter more than storage design

    Epic’s control over Unreal is a bigger adoption lever than any storage detail. Perforce is sticky because Unreal Editor and adjacent tooling already assume it, and teams accept a lot of operational pain in exchange for that support. If Lore becomes the first-class path inside Unreal, studios can justify switching even if the underlying ideas are not revolutionary.

    For infrastructure bets, watch product integration more than architecture purity. A technically decent tool with native engine support can beat a technically better outsider that makes artists and designers fight the workflow.

      Attribution:
    • jayd16 #1
    • tlahtinen #1
    • dijit #1
  3. 03

    Game teams need access control Git cannot express

    The permissions argument was not about write protection on a branch. It was about restricting who can even read parts of a shared repository, often because of partner NDAs, unreleased features, or licensed content. Git’s repository-level access model pushes teams into split repos, submodules, encryption layers, or artifact indirection, which is manageable for code but ugly for asset-heavy production.

    If your org has mixed-trust contributors or partner-restricted assets, treat read-level access control as a first-order VCS requirement. Workarounds built above Git tend to reshape the repository around the tool instead of the work.

      Attribution:
    • Lucasoato #1
    • throw2ih020 #1
    • hhsecurity #1
  4. 04

    Perforce survives despite constant operational drag

    What made Lore compelling was not that Perforce is bad in the abstract, but that experienced users described a steady tax of reconciles, broken workspaces, awkward branching, brittle scripting, encoding surprises, and dedicated staff just to keep the system healthy. Perforce wins because it matches the asset workflow, not because teams enjoy operating it.

    An incumbent can stay dominant for years while still leaving a large opening for replacement. If your competitor is entrenched mainly by workflow fit, beating its operational burden is a credible go-to-market wedge.

      Attribution:
    • retroflexzy #1
    • arka2147483647 #1
    • ultrahax #1
  5. 05

    Data versioning and game assets are similar but not identical

    People building AI and data tooling recognized the same ingredients here: content-addressed storage, chunking, deduplication, and large binary history. But one commenter drew a useful line. AI artifacts are often write-once or slowly changing, while game assets are edited repeatedly by many contributors and need locking, role-specific workspaces, and engine-aware workflows. That changes the architecture that matters.

    Do not assume a “Git for data” system transfers cleanly into media production. Frequent mutable assets and human coordination needs make game pipelines a different product category, even if the storage primitives rhyme.

      Attribution:
    • dimatura #1 #2
    • dosshell #1
  6. 06

    Documentation quality hurt trust immediately

    Several technically sympathetic readers came away less confident because the docs looked LLM-generated, overlong, and imprecise. For a version control system, that reads as a process smell. The concern was not aesthetic. It was that a tool handling source of truth needs evidence of careful thinking in edge cases, and sloppy explanations suggest the opposite.

    If you launch developer infrastructure, your docs are part of the trust model. Weak docs can negate strong technical claims, especially when you are asking teams to bet their history and workflows on a new system.

      Attribution:
    • pkasting #1
    • noopprod #1
    • coldpie #1

Against the grain

  1. 01

    Rename handling may be worse than Git

    Lore’s explicit move staging raised concern because it appears to require users or tools to record renames deliberately, instead of inferring them later the way Git often can. That may be acceptable in a Perforce-style workflow, but it becomes friction if IDEs, codemods, or automation move files outside Lore’s own command path.

    Test how the system behaves with the tools that actually mutate your tree, not just the happy path in the CLI. Rename semantics can become a daily paper cut in large automated codebases.

      Attribution:
    • maccard #1
    • xboxnolifes #1
    • ibejoeb #1
  2. 02

    Epic may not be a durable steward

    A blunt objection was that Perforce’s biggest advantage is not elegance but staying power. Studios know it will still exist because it is the vendor’s core business. Lore could be strategically abandoned by Epic with little impact on Epic itself, which makes some teams wary of building core infrastructure around it this early.

    Before adopting Lore, ask who will maintain it if Epic’s priorities change. Open source lowers the worst-case risk, but it does not create an ecosystem, support model, or migration path by itself.

      Attribution:
    • fg137 #1
  3. 03

    The project is not fully open yet

    Some readers pushed back on the marketing language because the desktop client is still binary-only and depends on proprietary Epic components. The CLI and core repos are open, but the most accessible client is not. For a tool aimed at artists and designers, that gap matters more than it would for a programmer-only utility.

    Treat the current release as open core tooling plus a promised future client, not a fully open end-user stack. If GUI adoption is central for your team, wait for the source release or verify the CLI and APIs are enough.

      Attribution:
    • O5vYtytb #1
    • Wowfunhappy #1
    • iceweaselfan44 #1

In plain english

Git LFS
Git Large File Storage, an extension to Git that stores large files outside the main Git object store and replaces them with lightweight pointers.
Hydration
In this context, downloading or materializing actual file contents only when they are needed, instead of storing every file locally up front.
MIT License
A permissive open source software license that allows broad reuse, modification, and commercial use with minimal restrictions.
Perforce
A long-running proprietary version control system, also called Helix Core, widely used in game development for large files and centralized workflows.

Reference links

Lore and implementation details

Competing or related version control tools

  • Perforce Helix Core
    The incumbent proprietary system Lore is most often compared against
  • Diversion
    Another game-oriented asset versioning product mentioned as a competitor
  • Oxen
    Open source large-asset versioning tool mentioned as a related project
  • Pachyderm
    Data versioning system cited as solving adjacent large-binary problems
  • LakeFS
    Another data versioning system mentioned for comparison
  • Jujutsu
    Alternative VCS mentioned in side discussions about better Git interfaces
  • Pijul
    Alternative VCS cited in discussion of new version control designs

Git internals and ecosystem references

Game development workflow references

Documentation and critique references