It’s optimized for projects—including games and entertainment—that combine code with large binary assets, and caters for the needs of developers and artists alike.
Wow, someone finally got sick enough of Perforce's multi-decade monopoly to do something about it.
Not in this case. The whole project and the doc is vibe coded.
There are obvious details wrong in the vibe coded design doc.
If the LLM can't get the English right, why would you trust it to get the code right?
Do you really want to trust your source code to vibe-coded software that gets it right 97% of the time? You're okay with possible data corruption or loss 3% of the time?
The design doc has a lot of LLM markers, from weird obsessions with irrelevant details to missing discussions:
making the case for alternatives, which in turn would lead to strengthening the case for your own decisions
getting a bunch of details wrong, such as "Text-first vs binary-first. Mercurial and Sapling are designed around textual histories: line-oriented merges, evolve workflows, text-shaped diffs are first-class. Lore is binary-first (§13); text features are layered on top of an opaque-bytes substrate." -- this is just wrong, Mercurial also has text features layered on top of a binary object model.
As a former dev on Mercurial/Sapling who believes LLMs can be used to improve rigor (eg by pointing out alternatives the team hadn't yet considered), it was a very disappointing read. There is a lot of merit to some of the decisions here, but I would have really liked to see a rigorously-written document.
Mercurial being "text-first" seems accurate to me? All it knows about binary files is that if a file contains \x00, it says "binary file" instead of trying to print it. And if you change a binary file, it's still splitting on \n characters to store a delta in the revlog. There has been talk of being smarter and picking a better delimiter but I don't think that's ever happened.
True, but the fact that revlogs split on \n is an implementation detail (and also one that Sapling moved away from, I believe). The "line-oriented merges, evolve workflows, text-shaped diffs" bit is all not really relevant -- all of those would still exist as a layer on top if revlogs didn't split on \n. Over-indexing on an detail like that without thinking how necessary it is is a pretty classic LLM tell.
2026-06-17 12:56 (Users)
Story: Epic Games announces Lore version control system
Action: changed tags from "release vcs" to "release vcs vibecoding"
Reason: Automatically changed from user suggestions
It's intended for repos with large blobs like video game assets, so it kind of makes sense that their own source code is still managed with git and hosted on github.
that's very history-of-git-shaped. though i guess that's irrelevant to the actual perception that two version control systems announcements in the same week did make me wonder why. thank you for the clarification, though. i'll look into perforce later and what it actually is
Cursor Origin eng here. We're not making a new VCS! Just a new forge that's Git-backed and Git-compatible. No need to learn a new thing, and the UX should feel familiar to Github users (but yes, it will support stacked changes and work with Graphite, and we're looking into making it ergonomic for jj users too).
Seeing Linear's PR feature, I would not mind them doing a throw at a VCS as well. They're building pretty much everything else around it, so it stands to reason that they would build that part as well.
I'm genuinely curious what features you think a fresh project is going to ship with that are not in GitLab?
I briefly considered widening my question to include Forgejo et al, but I think at this second those other "lighter" forges are not going directly after the same audience as GitHub users
Is Gitlab compelling? I've used it in the past and I know it exists but…
It's actions framework used to be quite good but I haven't kept up with how it's evolved. What we would be looking for in a Github replacement is uptime and security. Github has a huge attack surface and seems essentially insecurable.
I don't get it. The whole point of having a nice VCS history is have something coherent and understandable to the human. We don't just commit like it's autosave and then push/merge the changes, we curate them into atomic commits. So why would i store all garbage in my VCS? Are they betting on store everything, figure out later what is usefull, now that we have AI?
I like the way JetBrains' local history behaves for auto-save. deltadb reads (to me) like a collaborative version of that, as opposed to a full on VCS. If I'm reading it correctly, you'd still commit to your VCS, and that'd be the state "of record", but you could collaborate on what used to be local changes.
By my read, @kalkin, deltadb is more likely to keep garbage out of your real VCS. I'm not imagining it replacing git or mercurial, but being used on top of it.
Maybe that's just my bias given how nice JetBrains' local history has been for just that kind of thing, and prior wishes I could sync mine with someone else before I was ready for a real commit.
«Store every manual action, query the window of time if it ever becomes relevant for investigating» was viable even without LLMs.
If enough people wanted a nice VCS history maximally understandable to humans, tools that keep track of what was the original branch of a commit (Mercurial, Monotone, Bazaar) would either keep Git in a huge-repo niche, or push Git towards syncing reflog. Git choices make sense for the kernel scale where the history is huge enough that not every small-project history-browsing workflow is feasible.
So judging on revealed preferences of not caring much about history when one can care, autosave with better tooling is a plausible tool that can interest people if it works well enough and proves itself reliable.
I mean Git’s reign wasn’t gonna last forever… I’m happy to hear of VCS shakeup, but I was hoping something else. I’m turned off from the keyword “centralized”, to needing to enable JS just to get information from the page, to the ‘Join Discord’ as the ‘community’ option.
Folks in the Unreal Engine game dev space have been hearing the scuttlebutt that Epic has been working on a new VCS for years, so when the announcement dropped yesterday, I didn't even think about how it lined up with other experimental VCS announcements. That said, there has been significant investment from Epic in game DevOps infrastructure since the 2020 quarantine, and Lore compliments Horde (CI/CD, DevEx, build artifact hosting and distribution, replacing Jenkins et al) and Unreal Build Accelerator (distributed compilation, ephemeral build agent management in public clouds and asset processing, replacing Incredibuild + Incredibuild Cloud).
Like everything Epic for game development, I have to imagine Lore is a "frontier" product. Nearly everything they release is of a quality that "works okay for Epic/Fortnite", and you're welcome to adapt it how you wish. My current expectation is that it will be a while before Lore feels viably useful outside of the Unreal context, but as someone who has administered Perforce installs in the past, I'd be happy to overlook a lot of rough edges in the software if the solution doesn't feel like it's supported by twigs and bailing wire.
Meta: Thanks for merging the posts, I missed the one posted earlier. I couldn't find a way to do it myself after people flagged my post as a dupe, is that an action only mods can take?
I only skimmed the quick-start and other docs, but did anyone see how they intend to handle conflicts in binary files? That sounds like a context dependent rabbit hole.
How would you handle it other than pick one or the other? And have a process where it's clear who's doing what so you minimize the chances of this happening in the first place.
icefox | 10 days ago
Wow, someone finally got sick enough of Perforce's multi-decade monopoly to do something about it.
lobo | 10 days ago
why is it tagged as vibecoding now? i'm pretty sure it wasn't when i first saw it
ucirello | 10 days ago
I am afraid the vibecoded tag is losing its signal strength.
JordiGH | 9 days ago
Not in this case. The whole project and the doc is vibe coded.
There are obvious details wrong in the vibe coded design doc.
If the LLM can't get the English right, why would you trust it to get the code right?
Do you really want to trust your source code to vibe-coded software that gets it right 97% of the time? You're okay with possible data corruption or loss 3% of the time?
sunshowers | 10 days ago
The design doc has a lot of LLM markers, from weird obsessions with irrelevant details to missing discussions:
As a former dev on Mercurial/Sapling who believes LLMs can be used to improve rigor (eg by pointing out alternatives the team hadn't yet considered), it was a very disappointing read. There is a lot of merit to some of the decisions here, but I would have really liked to see a rigorously-written document.
mk12 | 9 days ago
Mercurial being "text-first" seems accurate to me? All it knows about binary files is that if a file contains \x00, it says "binary file" instead of trying to print it. And if you change a binary file, it's still splitting on \n characters to store a delta in the revlog. There has been talk of being smarter and picking a better delimiter but I don't think that's ever happened.
sunshowers | 9 days ago
True, but the fact that revlogs split on
\nis an implementation detail (and also one that Sapling moved away from, I believe). The "line-oriented merges, evolve workflows, text-shaped diffs" bit is all not really relevant -- all of those would still exist as a layer on top if revlogs didn't split on\n. Over-indexing on an detail like that without thinking how necessary it is is a pretty classic LLM tell.mdaniel | 9 days ago
I'd guess someone spotted the references to claude in the initial dump, and noticed that the references have since increased
gerikson | 10 days ago
From the modlog:
riki | 10 days ago
Is it just me, or is this the first public Epic Games project written in Rust?
mariusor | 10 days ago
I think their debugger (née RAD debugger) has been worked on in public for longer.
jesseb34r | 9 days ago
But the RAD Debugger is written in C not Rust?
mariusor | 9 days ago
Oops... I missed the very end of parent's post, which, I guess, is quite a feat since it's barely one line long. :D
vpol | 10 days ago
Am I the only one who’s first thought was: “shouldn’t it be hosted on… lore?”
Gaelan | 10 days ago
The commits all have something like this at the bottom:
So there seems to be some sort of mirroring going on.
riking | 9 days ago
Looks very similar to the
PiperOrigin-RevIdfooter on Google projects (which is also a Perforce successor).taskyliz | 10 days ago
It's intended for repos with large blobs like video game assets, so it kind of makes sense that their own source code is still managed with git and hosted on github.
mdaniel | 9 days ago
As a competing theory: if this was an internal Epic tool, and is only at 0.8.3, it is likely not hardened against hanging it out on the wild Internet
skade | 9 days ago
It was an internal tool, the readme says so. It’s part of the Fortnight Creator Studio (or similar).
mdaniel | 9 days ago
MIT https://github.com/EpicGames/lore/blob/v0.8.3/LICENSE
luiz | 10 days ago
This + Cursor's latest VCS news makes me think everyone's out to make a VCS nowadays...
heavyrain266 | 10 days ago
Lore solves a very different problem, it tries to become a replacement for Perforce that stagnated, and is relatively expensive nowadays.
luiz | 9 days ago
that's very history-of-git-shaped. though i guess that's irrelevant to the actual perception that two version control systems announcements in the same week did make me wonder why. thank you for the clarification, though. i'll look into perforce later and what it actually is
oneirine | 9 days ago
Cursor Origin eng here. We're not making a new VCS! Just a new forge that's Git-backed and Git-compatible. No need to learn a new thing, and the UX should feel familiar to Github users (but yes, it will support stacked changes and work with Graphite, and we're looking into making it ergonomic for jj users too).
Not an ad, just wanted to clarify :)
alper | 9 days ago
Seeing Linear's PR feature, I would not mind them doing a throw at a VCS as well. They're building pretty much everything else around it, so it stands to reason that they would build that part as well.
We might be rid of Github this year still!
mdaniel | 9 days ago
I'm genuinely curious what features you think a fresh project is going to ship with that are not in GitLab?
I briefly considered widening my question to include Forgejo et al, but I think at this second those other "lighter" forges are not going directly after the same audience as GitHub users
alper | 9 days ago
Is Gitlab compelling? I've used it in the past and I know it exists but…
It's actions framework used to be quite good but I haven't kept up with how it's evolved. What we would be looking for in a Github replacement is uptime and security. Github has a huge attack surface and seems essentially insecurable.
pyfisch | 9 days ago
Zed (the text editor) announced a VCS as well in the last week: https://zed.dev/blog/introducing-deltadb
kalkin | 9 days ago
I don't get it. The whole point of having a nice VCS history is have something coherent and understandable to the human. We don't just commit like it's autosave and then push/merge the changes, we curate them into atomic commits. So why would i store all garbage in my VCS? Are they betting on store everything, figure out later what is usefull, now that we have AI?
JordiGH | 9 days ago
Speak for yourself. Many people, maybe even most people really do want an autosave and could not care less about atomic commits.
I am not one of those people, but they seem to be everywhere.
hoistbypetard | 9 days ago
I like the way JetBrains' local history behaves for auto-save. deltadb reads (to me) like a collaborative version of that, as opposed to a full on VCS. If I'm reading it correctly, you'd still commit to your VCS, and that'd be the state "of record", but you could collaborate on what used to be local changes.
By my read, @kalkin, deltadb is more likely to keep garbage out of your real VCS. I'm not imagining it replacing git or mercurial, but being used on top of it.
Maybe that's just my bias given how nice JetBrains' local history has been for just that kind of thing, and prior wishes I could sync mine with someone else before I was ready for a real commit.
k749gtnc9l3w | 9 days ago
«Store every manual action, query the window of time if it ever becomes relevant for investigating» was viable even without LLMs.
If enough people wanted a nice VCS history maximally understandable to humans, tools that keep track of what was the original branch of a commit (Mercurial, Monotone, Bazaar) would either keep Git in a huge-repo niche, or push Git towards syncing reflog. Git choices make sense for the kernel scale where the history is huge enough that not every small-project history-browsing workflow is feasible.
So judging on revealed preferences of not caring much about history when one can care, autosave with better tooling is a plausible tool that can interest people if it works well enough and proves itself reliable.
toastal | 9 days ago
I mean Git’s reign wasn’t gonna last forever… I’m happy to hear of VCS shakeup, but I was hoping something else. I’m turned off from the keyword “centralized”, to needing to enable JS just to get information from the page, to the ‘Join Discord’ as the ‘community’ option.
belthesar | 9 days ago
Folks in the Unreal Engine game dev space have been hearing the scuttlebutt that Epic has been working on a new VCS for years, so when the announcement dropped yesterday, I didn't even think about how it lined up with other experimental VCS announcements. That said, there has been significant investment from Epic in game DevOps infrastructure since the 2020 quarantine, and Lore compliments Horde (CI/CD, DevEx, build artifact hosting and distribution, replacing Jenkins et al) and Unreal Build Accelerator (distributed compilation, ephemeral build agent management in public clouds and asset processing, replacing Incredibuild + Incredibuild Cloud).
Like everything Epic for game development, I have to imagine Lore is a "frontier" product. Nearly everything they release is of a quality that "works okay for Epic/Fortnite", and you're welcome to adapt it how you wish. My current expectation is that it will be a while before Lore feels viably useful outside of the Unreal context, but as someone who has administered Perforce installs in the past, I'd be happy to overlook a lot of rough edges in the software if the solution doesn't feel like it's supported by twigs and bailing wire.
typesanitizer | 9 days ago
Meta: Thanks for merging the posts, I missed the one posted earlier. I couldn't find a way to do it myself after people flagged my post as a dupe, is that an action only mods can take?
mrpossoms | 9 days ago
I only skimmed the quick-start and other docs, but did anyone see how they intend to handle conflicts in binary files? That sounds like a context dependent rabbit hole.
alper | 9 days ago
How would you handle it other than pick one or the other? And have a process where it's clear who's doing what so you minimize the chances of this happening in the first place.