Programming, graphics, games, media, C++, Windows, Internet and more...
Thu
18
Jun 2026
June 17th, 2026, Epic Games announced Lore - a new version control system for software developers, to compete with Git and Perforce. Being old enough to have worked with the old CVS and SVN, and having experience working with Git and Perforce, I am quite interested in what changes this new system brings.
In my article Thoughts Beyond C++ from December 2024, I described my opinion about the problems I can see with current version control systems and the improvements a better one could bring, especially for game development. Let's see whether Lore advances any of these topics.
Key pages about Lore:
I didn't test the app myself so far, but I've read some of the docs to get an idea of what it is and how it compares to Git and Perforce. tl;dr: It looks promising, although not revolutionary. Here is a summary and my thoughts.
The fact that it's made by Epic, the company behind Unreal Engine and Fortnite, is already a big plus, because it increases the chances of it being well supported and maintained. Despite being a pre-release version 0.x as a standalone product, it's already battle-tested, because when it was formerly called Unreal Revision Control, it was the built-in version control system for UEFN, where creators have been using it to version their Fortnite islands. Which means its lineage is already used in UEFN, but the standalone open-source product should still be treated as early.
Another advantage is that it's open source, under an MIT license, which also means it's free to use for personal as well as commercial purposes. Git is also open source, but other VCSs like Perforce/P4/Helix Core, Plastic, or Ark are not. Only the desktop client is available as a binary download and is not open source yet because it depends on proprietary components, but Epic is committed to open-sourcing it later.
The fact that it's written in Rust is also a good sign, increasing the chances of good performance (because Rust is a native language, unlike Java, C#, or JavaScript), as well as security and stability (because strong memory safety in Rust helps avoid many bugs that are notorious in C and C++). Offering APIs for C/C++, C#, Rust, Go, Python, and JavaScript is also great, because it can facilitate the development of tools that can integrate with this system - whether alternative GUI clients just for Lore, or support for it added to various text/code/asset editors.
Of course, a VCS like this encompasses many design decisions and many technical details behind the actual implementation or the shape of the API, CLI, or GUI. I will avoid low-level details here (like the use of Merkle trees) and instead focus on what's visible to the user.
The main promise of Lore is better handling of large binary files compared to Git (including Git with LFS). Epic claims that binary files rather than text files are natural to their system, with no conversions like line endings happening in the background, and any text-based processing implemented on top of the core system. Data stored in a repository is deduplicated not only at the level of an entire file, but also per fragment, which saves space even when only a part of a large binary file changes between revisions. Their documentation states that thanks to clever algorithms using data hashing, it works even when some data is inserted in the middle of a file! This is great news for game developers and other developers working with large binary assets.
Moreover, Epic claims that Lore is scalable in multiple "axes", allowing it to work efficiently with many repositories, many branches per repository, many files, large binary files, etc. If this is true, it makes the system a good fit for extensive software projects, like video games.
Lore seems to follow Git's approach of downloading the data from the remote repository first to a hidden directory .lore (similarly to .git), and then copying it to the working directory files. It means that, unlike Perforce, it may require disk space of at least 2x the working copy size, similarly to Git with LFS (subject to compression and deduplication). Lore claims to use sparse/lazy fetching as the default mode, but I suspect this just means that only the selected revision of all the files is downloaded rather than all their historical versions.
The advantage of this approach is, of course, the ability to inspect commit history, switch branches, diff, commit, etc. fully offline (unless it needs fragments that were never fetched into the local cache), which is not possible in Perforce.
One feature that can help limit the required disk space is support for "views", which are inbound filters declaring which paths in the repository the user wants on disk. Unlike views in Perforce, this is not a fully flexible mapping between repository paths and local paths. Another nice feature is the possibility for multiple working copies on a user's machine to share a common local fragment store.
Lore's command set looks very similar to Git's, which might be considered an advantage or a disadvantage, depending on how you see it. Cheap and lightweight branches are definitely a plus. But I personally think Git is overly complicated, especially for non-programmers. Lore inherits most of its concepts. There is also a concept of "commit", followed by "push". Yet, Lore simplifies a few things compared to Git:
First, Git is a decentralized version control system at its core. Lore, on the other hand, defines one central repository. There are no multiple "remotes" to be added to the local cloned repo. Support for forks is planned for the future.
In Git, I never liked the concept of staging. The stage (index) in Git stores an additional copy of the files, so we may have a different version of the file contents committed as the latest on the current branch, a different one modified in the working directory, and a third one currently staged. That third version will be committed. I think this is confusing and unnecessary. Lore also has a concept of "stage" followed by "commit", but in Lore, staging pins the path, not the content: the commit captures whatever the file looks like at commit time, which I consider more intuitive.
Update 2026-06-19: As comments to my post on Blusky, Karl Schmidt noticed that Lore docs don't mention anything like "shelf" or "stash", while Sidney said that he considers Git staging useful as lite commits when trying some hacks. I still think that these are convenience features that can be built on top of local branches and commits, provided by a client app, and don't necessary need to be part of the core system.
Just like Git, Lore supports merges with squashing (the design doc mentions it, but I can't find it in the CLI documentation). My understanding is that, just like in Git, a squash commit forms a completely unrelated revision not parented to the branch being merged. So, we still need to choose between squashing (so we have a clean and simple history) or not squashing (so we retain the history of all intermediate commits). I'm hopeful that one day, some VCS will introduce a hierarchical commit history, so we don't need to choose between these options, but instead can expand and collapse a group of fine-grained commits into one larger feature/branch/release. But for now, Lore seems to strictly follow the approach popularized by Git.
Similarly to Git submodules, Lore also offers mounting a linked repository at a path inside another repository. It actually offers two similar features: "link" - which is stored in the repository - and "layer", which stays limited only to the local working copy. Unlike Git submodules, both of these Lore features offer cloning only a selected subdirectory of the repository, which I think is a major improvement.
Another important difference is access control. Lore has a concept of "partitions" as access boundaries: knowing a content hash is not enough to fetch the data unless the user has access to the partition where it lives. At the same time, identical fragments can still be deduplicated internally. This sounds useful for large studios with contractors, external partners, licensed IP, or assets that only some teams should see.
Lore also separates branch identity from branch name. In Git, a branch is basically a named reference to a commit. In Lore, a branch has a stable internal ID, while the human-readable name is a mutable mapping to that ID. This seems like a cleaner model for large centralized repositories with many long-lived, renamed, or archived branches.
Lore considers commit history immutable (kind of like a blockchain?), so there is no force-push or history rewrite. If a secret API key is pushed accidentally or the legal department orders the removal of something that has already been published, the file obliterate command is offered instead. It erases the file content, causing a "this fragment was obliterated" error when trying to fetch that data later. I think it's a nice and clean solution.
By the way, this doesn't solve the problem of removing accidentally leaked data in a commit message. The revision amend command can modify only the latest commit's message. I'm sure they will face this problem sooner or later, and it may be difficult to solve, because the system-design doc says a revision state contains a hash of serialized metadata, and that revision metadata includes the commit message.
Among smaller features, a nice command that I noticed in the docs is branch merge into, allowing the current branch to be merged into a target branch. Git doesn't have that. In Git, we have to switch to the target branch and only then can we merge from a source branch.
Lore supports file locking, but currently it “informs rather than blocks”. Lock enforcement is planned for the future. But I think this may already be OK, as long as all the client apps using Lore across the company respect these locks.
An interesting group of commands is file dependency. It allows setting dependencies between files. I can imagine the feature being used for huge asset repositories where a user or tool does not want to materialize "some folder," but rather "this asset and everything it needs." The CLI exposes dependency-based selective sync that only clones specified files and their dependencies.
Overall, I think Lore looks promising. It is very similar to Git, but it improves on many aspects that are important in game development. Epic, as a major player in this area, really has a chance to facilitate its adoption. Whether it really surpasses Git and Perforce in some applications depends a lot on the execution - whether it scales to large projects as well as promised, and whether the GUI client and IDE extensions will offer a good user experience.
But I think it could go further. The game industry faces challenges with managing large files beyond game source code and its accompanying assets. Thanks to the first-class API support, maybe Lore can be utilized not only by programmers' software committing their code changes, but also by other kinds of tools such as: