For context, since a lot of people on HN haven't worked on games - this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development.
Git is fine for text based files like code, but it's really bad at stuff like textures, 3D models, audio files, and other non-text files that game developers need to collaborate on. For example, one artist might need to obtain an exclusive lock on some art assets while editing them, because there is no sane way to merge two artists' async edits.
The SOTA in this area is Perforce (https://www.perforce.com/products/helix-core), a proprietary system. From what my gamedev friends tell me, when Perforce works it's great, but it hits enough snags that you need a tools engineer to manage it and occasionally fix issues manually. Git LFS is an alternative, but my gamedev friends all prefer Perforce especially when working on team projects beyond like 3-4 people.
Something else that git isn't good at: permissions. In gamedev, you might have proprietary work that you want to restrict to certain users. In P4, you can add restrictions to certain directories for only those who have signed the required NDAs. That's not something that you can do in git: it's all or nothing. Maybe you can do set something up with submodules, but that's going to upend your repository if you hadn't planned for it.
That's by design of git, you can't forget that git is first developed for a bazaar model of information flow, especially with a big decentrailized project like the Linux Kernel, not the silo and isolated corporate NDA and closed model you described. Git prefers open information and discourages information closures and segregation of information by placing restrictions exactly like this.
Git enthusiast would often tell you to do this separately with a submodule, and set permission on the version control forge software level (which means Gitea/Github private RBAC access to certain repos for cloning), sure, but that is also painful as hell.
But my point is that all of this is exactly by design from Linus Torvalds's need for Linux Kernel to replace BitKeeper. Git simply isn't the tool for everything, it was developed for a software project with liberalism in mind, but corporate stuff is monoculture and prefers proprietary, shut-in model, and the eat your own dog food mindset, and no wonder it is so painful to deal with.
I wonder how useful this could be as a generalized version control for regular user systems, as a way to rollback, or scrub through history. Presumably if this is designed to work at Epic and Big Game studio scale, it should work at home computer scale
Jonathan Blow found it convenient to represent all assets in a large number of text files, to enable merging. For instance he'd have one text file per entity on a map. The game and editor could read either this or the compiled binary version.
Jonathan Blow works with extremely small team sizes relative to the big studios. When you only have a couple people working on a project you don’t need all of the same coordination features.
He and Casey Muratory make a lot of cool instructive content, but their condescending attitude towards the industry always made me thing "Huh, must be really nice working alone and making all the decisions yourself."
I respect his work, but I had to unfollow him on Twitter because he was so condescending to everything and everyone except his loyal fan base.
He’s in a category of influencers who post constantly about gripes and grievances and smug superiority. Some people like that content but I can’t stand it.
I really like hearing about indie development and small teams, but you don’t have to present everything as condescending superiority over the industry. That’s not the part I find interesting.
I think there is an element of audience capture that sets up a self reinforcing feedback loop that drives out the normies and ends up rather cult like.
And then they usually back their words by doing things like "you claim that outputting text to a terminal emulator is a PhD level problem, so here I did it in a weekend".
Huge teams are more often than not the sign of bloat and inefficiences.
He's also the sort of person who I suspect works in a very idiosyncratic way, which is great for him and his mind but probably not everyone else. (This is not a criticism.)
That's fine for database-like meta-data (e.g. game entity properties), but not for images, videos or audio files. Just writing those as hex dumps into text files doesn't make them any easier to merge.
You really can't merge binary data, such as textures, meshes, audio, etc. It doesn't matter if you base64 encode the data and stuff it in a text file: it's a jumble of data (assuming this is the implication of what Blow did).
That sucks, git is so absolutely horrible. It's crazy to me that nobody has made anything better yet. Although I could start that myself and yet have not.
Git LFS has file locking, and no VCS can provide you with the tools for diffing binary assets. I don't see any meaningful difference between Perforce, Diversion or Lore and git + LFS + file locking. Unless there's a meaningful performance impact for large projects (I only work on small / medium projects), the capabilities are the same. However, I get excellent git support for code in any editor, as opposed to Diversion or Lore which have none.
Git LFS for example does not support file chunking. So a single byte change on a large (100s of gigs) file means downloading the whole file again. Lore does chunking of binary files which means faster downloads and better de-dupping on the backend.
I haven't made games for a long time so I can't speak for my experience, only my friends. From what I understand (1) Perforce has decent integrations with the game engine editors my friends work with, so editor support is no factor for them and (2) it has better delta support for the file types they work with - I believe Git LFS mostly uses a generic xdelta diff which is kind of mediocre at everything versus Perforce can understand different file types and be extended to support custom types.
I guess you never worked with anything but git? The devil is in the details, and those details generally suck more in git (or generally: distributed version control systems) than in traditional centralized VCS's.
Also git-lfs is a crutch that breaks more often than it works :/
(I agree for that for small game projects, git is mostly 'good enough', even without lfs).
Git LFS breaks so often that it can't be seen as a serious professional tool tbh. I've had nothing but trouble with it. If it wants to be serious it needs to be built into Git, not added as some after thought.
Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is:
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 10 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 290 bytes | 290.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
I know all of these things communicate something to the die-hard Git user, but for most people (even most people using Git, I bet) this is just complete gobbledegook. What the hell is "delta compression"? Why do I care how many threads it's using? What is an 'object' and what does it mean when it's 'local'? What does 'pack-reused' mean?
From the documentation, it looks like Lore does a bit better in this regard:
Pushing 1 fragment(s)
Pushed 1 fragment(s), 124.00 bytes
Pushing a3f8c2d1... to branch main
Pushed revision 1 -> a3f8c2d1... to branch main
I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades to just ignore it.
Those are just the sounds that animal makes. Live with the animal long enough, you learn how the sounds correspond to its internal states, even if you don’t really know what they mean.
I’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push
He makes a good tool? Honestly I don’t get the git hate on HN. I’ve been using it for years with no issue. I just read the first 3 parts of the git book and never looked back. I even setup a git server at home with the basic tools.
"Full-surface API" is a feature nobody here has mentioned. Is that a dig at how git intentionally has no linkable library? I saw this earlier https://news.ycombinator.com/item?id=48470604
The premise is that Git-LFS sucks, so we need to build a new data versioning system (in Rust, from scratch). While I mostly agree with this premise, but there are already lots of existing (mature) data versioning systems with the same tricks under the hood:
I guess with AI, anyone can vibe code a content-addressed, chunk-level deduped, versioning system in Rust these days...
But jokes aside, Lore seems really cool! What's interesting is the realization that different domains/industries have similar problems, but they don't seem to be cross-polinating. In this case AI and Gaming both need a storage system that can version control large binary files at scale. I think there's lots of opportunities to share ideas here, but perhaps the lack of idea sharing (currently) creates opportunity!
Yeah, I'm still concerned about crystalline entities suddenly showing up. Have they ever fixed it? I don't see anything in the issue tracker, probably because no one was left last time to report it...
"Lore" is appropriate. Epic games is a very unethical company that steals from people. Myself in paticular. I bought Rocket League the game for linux from Psyonix. Epic bought Psyonix and immediately removed the game clients for linux and mac os. I can no longer play. They stole from me and many others. It'd be one thing if they just shut down the game entirely, but stealing it from only some people while keeping it going for others is worse than just killing games.
This looks very cool! I maintain a FreeCAD workbench for 3d model version control[0], and it currently uses git as the VCS, simply because that's what I was already using. Thinking long-term, I see it eventually morphing into a broader PDM (Product Data Management) system, perhaps even PLM (Product Lifecycle Management). Lore has a lot of the requirements already built-in, like centralized locking (better than SVN), and it's better suited for for binary files. I implemented the git backend as a protocol/port so it'd be pretty easy to swap it out. I'll be watching Lore closely.
> Git’s content-addressed revision graph is excellent, but it treats binary files as second-class citizens—large files require bolted-on LFS rather than first-class chunked storage, sparse checkouts have sharp edges in offline use, and there is no native multi-tenant isolation.
I'm trying to figure out what Lore can accomplish that git+LFS can't. I've read about big binaries chunking, native interface and permission, is there anything else? Weren't those problems already solvable in the git+LFS ecosystem?
If you've used git+LFS for any extended period of times, you'd know how often it breaks, especially when used with forges like GitHub. Both GitHub and Git treat LFS as an after-thought and second class citizen.
The fact that it's even referred to as git+LFS instead of just git... If I needed to work with large files frequently, I wouldn't want such a basic feature bolted on. Not a criticism of git, just can see why Epic doesn't use git.
> Open-source the desktop client so the community can build on its full graphical experience, not just download it. An early desktop client already exists as a binary download, but it isn't open source yet — it depends on some proprietary components, including Epic's internal design system. We're working to make all of it available in the open so that the client can ship as source alongside the rest of Lore. Lore is an open project, so it is important that the desktop client — which will be one of the main ways many people will interact with Lore — is also fully open so that the community is free to review, extend, and shape it.
Thanks. I still think it's a bit weird to say "fully" open source while your flagship client is currently closed. I realize they're referring to the VCS itself, but—well, if they just dropped the fully for the time being, I wouldn't bat an eye.
to be fair, that's just the desktop client. You can use or build on top of the CLI
they do say they will open source it, but who knows:
"It isn’t open source yet—it currently depends on some proprietary components, including Epic’s internal design system—but we’re committed to open-sourcing it in the future"
The five command part isn't really possible but you can use custom diffs for merges, git diff, etc. pretty easily. There are projects like diffsitter ( https://github.com/afnanenayet/diffsitter ) for doing more intelligent diffs like this for supported languages.
They’ve been dabbling in this space within Unreal Engine for a few years. Perforce is the de facto standard in AAA studios from my experience, curious to see what’s going to happen to them.
this looks cool for game development, because using Git for projects in Unity and Unreal Engine definitely has it's issues. I'm personally not a fan of Git LFS, especially since GitHub charges you to use it (which makes sense, binaries and assets are big, code is small, relatively speaking).
Lore itself is not an example of a program that meaningfully benefits from any of the key features of Lore.
Lore is meant for situations where your repository is going to contain gigabytes of binary files, such as art assets for games. Git is technically great at everything but that, and even the external solutions for that situation still kind of suck.
Git does great with text files, but game development contains a lot of binary assets (textures, videos, 3d models) and correspondingly huge repos. git-lfs tries to patch around that, but that makes a complex tool that creatives struggle to understand even more complex. Perforce is a pretty popular solution, and was used by Epic in the past
Have to think they're doing this out of a real need, given they were already using Perforce and must've considered Git too. It's also not like 2010s when version control was a hyped thing.
> 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.
When you have a game that weighs in at 100GB, only a tiny fraction of that is built from code. The rest of it is binary assets that most VCSs struggle with. What makes this worth considering is the fact that they designed it to handle binary assets.
Citizen Sleeper, the game that is going free tomorrow on the Epic store is really good. Space Cyberpunk themed RPG/Survival Sim.
It is interesting that people are so cynical about Epic giving out free games. I get that people love Steam, but competition in the storefront market is not bad.
I definitely have. But they're all the games that they gave out in the early days, the more recent games haven't really appealed to me. And it didn't convince me to spend any money, I still haven't spent a single cent on anything Epic Games.
I've been getting them for years now and have enjoyed many of them (though not a large percentage), and would love to use the Epic store more, if only they would implement some version of reviews/scores. Without that, I feel that I can't trust them as a marketplace.
i've paid for brotato (Its a pretty good game, it was worth my money) and played city skylines (which i haven't paid for due to its excessive amount of dlcs)
Well it seems to be intended for repos with large blobs like video games so it kind of makes sense that their own pure source code is still managed with git.
Epic's Unreal Engine development is made in Perforce, and then it was mirrored to git/Github. Or that's how it was a couple years ago. That's kind of expected, VCS is one thing, a forge is another thing.
Interesting to note that this does not seem like a DVCS in the traditional sense because it depends on coordinating with a central server where all repositories will be hosted. I can't tell if servers can pull/push from eachother.
Their docs seem entirely LLM written. It seems especially obvious in the FAQ. While I'm not against using LLMs for writing assistance, they've left a lot of the unnecessary language and typical stylistic choices in there, which erodes my trust in the project a bit. Perhaps it's a very good game-oriented version control system, but the lack of human attention on the docs makes me wonder how much they care
I reluctantly agree. I was interested to read the system design doc[1] but it's so many pages long and so full of redundant statements and needless details[2] that I gave up a couple sections in. The numerous "it's not X, it's Y" constructions give the game away. If they can't be bothered to read these docs themselves, why should I?
Anyway it's probably fine software and I am genuinely going to give it a shot for a usecase I have involving large image files. But the LLM-generated docs don't inspire confidence.
[2] They literally have a section header "10.1 Revision state as a 320-byte fragment". The byte size isn't even relevant in the code as an implementation detail, much less belongs in a design doc. No one read this doc before publishing it.
Yeah, I agree about the docs. I started on the system design page and my head started to swim after about 5 minutes. So exhausting to read!
On the flip side, I expect the project itself will be workable - well, assuming they're actually using it themselves! UE is a big pile of Stuff on its own, and Fortnite must have god knows how much additional crap in there, so if this is (or will be) their replacement for Perforce internally, then it'll be getting a good deal of testing. (If they're just chucking it over the wall, though... well, sheesh, you first...)
(Perforce is the standard thing for games, and pretty well it works too, and hopefully this will deliver it a well-needed kick. It was sold to private equity about 10 years ago, and it feels like they've been coasting ever since. (Perhaps users in other sectors are happier though?))
Yeah, I hope I'm wrong, but it feels a little bit like "planned project no longer has internal support, let's see if we can make it open-source to garner goodwill and recoup some of our investment." Which isn't the worst thing that can happen.
The incredible laggyness of that website does not inspire confidence. Much of the text selection is also broken, and chrome consumes nearly a full core trying to render.. something?
Its remarkable that anyone thought this website was fit for release, and it gives off strong slop vibes
I also have absolutely zero trust in a product like version control being provided by a for-profit company. It seems like a terrible idea to tie your software stack to Epic Games of all people, given their track record
This is just going to become another way to lock developers into UE. Then they will start charging for licenses, same as Unity did for its versioning feature. It might be open source but that doesn’t stop the commercial use of it being charged for.
For context, since a lot of people on HN haven't worked on games - this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development.
Git is fine for text based files like code, but it's really bad at stuff like textures, 3D models, audio files, and other non-text files that game developers need to collaborate on. For example, one artist might need to obtain an exclusive lock on some art assets while editing them, because there is no sane way to merge two artists' async edits.
The SOTA in this area is Perforce (https://www.perforce.com/products/helix-core), a proprietary system. From what my gamedev friends tell me, when Perforce works it's great, but it hits enough snags that you need a tools engineer to manage it and occasionally fix issues manually. Git LFS is an alternative, but my gamedev friends all prefer Perforce especially when working on team projects beyond like 3-4 people.
Something else that git isn't good at: permissions. In gamedev, you might have proprietary work that you want to restrict to certain users. In P4, you can add restrictions to certain directories for only those who have signed the required NDAs. That's not something that you can do in git: it's all or nothing. Maybe you can do set something up with submodules, but that's going to upend your repository if you hadn't planned for it.
That's by design of git, you can't forget that git is first developed for a bazaar model of information flow, especially with a big decentrailized project like the Linux Kernel, not the silo and isolated corporate NDA and closed model you described. Git prefers open information and discourages information closures and segregation of information by placing restrictions exactly like this.
Git enthusiast would often tell you to do this separately with a submodule, and set permission on the version control forge software level (which means Gitea/Github private RBAC access to certain repos for cloning), sure, but that is also painful as hell.
But my point is that all of this is exactly by design from Linus Torvalds's need for Linux Kernel to replace BitKeeper. Git simply isn't the tool for everything, it was developed for a software project with liberalism in mind, but corporate stuff is monoculture and prefers proprietary, shut-in model, and the eat your own dog food mindset, and no wonder it is so painful to deal with.
Doesn't git crypt solve this? You can have encrypted in a repo that will be auto decrypted if you have a working key.
I wonder how useful this could be as a generalized version control for regular user systems, as a way to rollback, or scrub through history. Presumably if this is designed to work at Epic and Big Game studio scale, it should work at home computer scale
Jonathan Blow found it convenient to represent all assets in a large number of text files, to enable merging. For instance he'd have one text file per entity on a map. The game and editor could read either this or the compiled binary version.
Jonathan Blow works with extremely small team sizes relative to the big studios. When you only have a couple people working on a project you don’t need all of the same coordination features.
He and Casey Muratory make a lot of cool instructive content, but their condescending attitude towards the industry always made me thing "Huh, must be really nice working alone and making all the decisions yourself."
I respect his work, but I had to unfollow him on Twitter because he was so condescending to everything and everyone except his loyal fan base.
He’s in a category of influencers who post constantly about gripes and grievances and smug superiority. Some people like that content but I can’t stand it.
I really like hearing about indie development and small teams, but you don’t have to present everything as condescending superiority over the industry. That’s not the part I find interesting.
I think there is an element of audience capture that sets up a self reinforcing feedback loop that drives out the normies and ends up rather cult like.
IMO this is just garden variety effects of being a programming influencer. It’s a weird position to be in.
I think being influential just does that to people, with high regularity.
And then they usually back their words by doing things like "you claim that outputting text to a terminal emulator is a PhD level problem, so here I did it in a weekend".
Huge teams are more often than not the sign of bloat and inefficiences.
Isn't that kind of the point though? Doing more with less?
He's also the sort of person who I suspect works in a very idiosyncratic way, which is great for him and his mind but probably not everyone else. (This is not a criticism.)
He uses SVN and specifically has stated that Git isn't suitable for the work he does due to big binaries in source control.
How do you merge changes to a texture, mesh, audio file, etc?
That's fine for database-like meta-data (e.g. game entity properties), but not for images, videos or audio files. Just writing those as hex dumps into text files doesn't make them any easier to merge.
You really can't merge binary data, such as textures, meshes, audio, etc. It doesn't matter if you base64 encode the data and stuff it in a text file: it's a jumble of data (assuming this is the implication of what Blow did).
That sucks, git is so absolutely horrible. It's crazy to me that nobody has made anything better yet. Although I could start that myself and yet have not.
With respect, were you around to use any of its predecessors?
There are some projects:
* https://github.com/jj-vcs/jj
* https://nest.pijul.com/pijul/pijul
turns out version control is hard
Git LFS has file locking, and no VCS can provide you with the tools for diffing binary assets. I don't see any meaningful difference between Perforce, Diversion or Lore and git + LFS + file locking. Unless there's a meaningful performance impact for large projects (I only work on small / medium projects), the capabilities are the same. However, I get excellent git support for code in any editor, as opposed to Diversion or Lore which have none.
Git LFS for example does not support file chunking. So a single byte change on a large (100s of gigs) file means downloading the whole file again. Lore does chunking of binary files which means faster downloads and better de-dupping on the backend.
Permissions is another thing. Git permissions are done one a per repo basis.
https://epicgames.github.io/lore/explanation/system-design/#...
I haven't made games for a long time so I can't speak for my experience, only my friends. From what I understand (1) Perforce has decent integrations with the game engine editors my friends work with, so editor support is no factor for them and (2) it has better delta support for the file types they work with - I believe Git LFS mostly uses a generic xdelta diff which is kind of mediocre at everything versus Perforce can understand different file types and be extended to support custom types.
I guess you never worked with anything but git? The devil is in the details, and those details generally suck more in git (or generally: distributed version control systems) than in traditional centralized VCS's.
Also git-lfs is a crutch that breaks more often than it works :/
(I agree for that for small game projects, git is mostly 'good enough', even without lfs).
Git LFS breaks so often that it can't be seen as a serious professional tool tbh. I've had nothing but trouble with it. If it wants to be serious it needs to be built into Git, not added as some after thought.
don't think it supports branches
it's also tough when you have 1TB of data, over 1mm files and you might want to lock hundreds files in one go
Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is:
I know all of these things communicate something to the die-hard Git user, but for most people (even most people using Git, I bet) this is just complete gobbledegook. What the hell is "delta compression"? Why do I care how many threads it's using? What is an 'object' and what does it mean when it's 'local'? What does 'pack-reused' mean?From the documentation, it looks like Lore does a bit better in this regard:
I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades to just ignore it.
> It's probably just something no one has thought of doing
There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.
Luckily it’s an open source project so you could go in and clean up the ux.
The lights are blinking, so everything must be working!
I actually like this underlying logs. Could have a concise / project level summary though.
Those are just the sounds that animal makes. Live with the animal long enough, you learn how the sounds correspond to its internal states, even if you don’t really know what they mean.
I’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push
This is what happens when a kernel developer creates tools that need some kind of UX (I say this both as a shitty UX developer and Linus fan)
He makes a good tool? Honestly I don’t get the git hate on HN. I’ve been using it for years with no issue. I just read the first 3 parts of the git book and never looked back. I even setup a git server at home with the basic tools.
Git as a data structure is clever, but Git as a CLI is atrocious.
Yes, the famous debate between plumbing and porcelain
Still the porcelain is more like cold stainless steel
I use GitHub desktop app that pushes to my local Gitlab. It’s a nice and simple GUI, it might be what you’re looking for.
"Full-surface API" is a feature nobody here has mentioned. Is that a dig at how git intentionally has no linkable library? I saw this earlier https://news.ycombinator.com/item?id=48470604
The premise is that Git-LFS sucks, so we need to build a new data versioning system (in Rust, from scratch). While I mostly agree with this premise, but there are already lots of existing (mature) data versioning systems with the same tricks under the hood:
- Pachyderm (Go): https://github.com/pachyderm/pachyderm
- XetHub (acquired by HuggingFace): https://huggingface.co/blog/xethub-joins-hf
- LakeFS (Go): https://github.com/treeverse/lakeFS
- Oxen (Rust): https://github.com/Oxen-AI/Oxen
I guess with AI, anyone can vibe code a content-addressed, chunk-level deduped, versioning system in Rust these days...
But jokes aside, Lore seems really cool! What's interesting is the realization that different domains/industries have similar problems, but they don't seem to be cross-polinating. In this case AI and Gaming both need a storage system that can version control large binary files at scale. I think there's lots of opportunities to share ideas here, but perhaps the lack of idea sharing (currently) creates opportunity!
I'd trust this project more if it was named Data.
Yeah, I'm still concerned about crystalline entities suddenly showing up. Have they ever fixed it? I don't see anything in the issue tracker, probably because no one was left last time to report it...
Oh brother.
Don't be too hard on Lore.
Dunno, this seems fully functional?
All Data is Lore. I mean lore is a superset of data. I mean data is lore with a special attribute.
I'm not just picking nits here. And this is not cynicism.
so there you go.
I'm not the parent, but I suppose it was a joke reference to Star Trek where Data (an android character) discovers he has a brother named Lore [0].
[0] https://en.wikipedia.org/wiki/List_of_minor_Star_Trek:_The_N...
an evil brother
The likely source for Lore - https://memory-alpha.fandom.com/wiki/Lore
"Lore" is appropriate. Epic games is a very unethical company that steals from people. Myself in paticular. I bought Rocket League the game for linux from Psyonix. Epic bought Psyonix and immediately removed the game clients for linux and mac os. I can no longer play. They stole from me and many others. It'd be one thing if they just shut down the game entirely, but stealing it from only some people while keeping it going for others is worse than just killing games.
This looks very cool! I maintain a FreeCAD workbench for 3d model version control[0], and it currently uses git as the VCS, simply because that's what I was already using. Thinking long-term, I see it eventually morphing into a broader PDM (Product Data Management) system, perhaps even PLM (Product Lifecycle Management). Lore has a lot of the requirements already built-in, like centralized locking (better than SVN), and it's better suited for for binary files. I implemented the git backend as a protocol/port so it'd be pretty easy to swap it out. I'll be watching Lore closely.
[0] https://github.com/eblanshey/HistoryWorkbench
> Git’s content-addressed revision graph is excellent, but it treats binary files as second-class citizens—large files require bolted-on LFS rather than first-class chunked storage, sparse checkouts have sharp edges in offline use, and there is no native multi-tenant isolation.
I'm trying to figure out what Lore can accomplish that git+LFS can't. I've read about big binaries chunking, native interface and permission, is there anything else? Weren't those problems already solvable in the git+LFS ecosystem?
If you've used git+LFS for any extended period of times, you'd know how often it breaks, especially when used with forges like GitHub. Both GitHub and Git treat LFS as an after-thought and second class citizen.
The fact that it's even referred to as git+LFS instead of just git... If I needed to work with large files frequently, I wouldn't want such a basic feature bolted on. Not a criticism of git, just can see why Epic doesn't use git.
>fully open source >look inside >Lore Desktop Client is available as binaries only, download the installer for your platform here:
https://epicgames.github.io/lore/roadmap/#desktop-client
> Open-source the desktop client so the community can build on its full graphical experience, not just download it. An early desktop client already exists as a binary download, but it isn't open source yet — it depends on some proprietary components, including Epic's internal design system. We're working to make all of it available in the open so that the client can ship as source alongside the rest of Lore. Lore is an open project, so it is important that the desktop client — which will be one of the main ways many people will interact with Lore — is also fully open so that the community is free to review, extend, and shape it.
Thanks. I still think it's a bit weird to say "fully" open source while your flagship client is currently closed. I realize they're referring to the VCS itself, but—well, if they just dropped the fully for the time being, I wouldn't bat an eye.
It’s pretty obvious the entire surrounding text of this project (and presumably the code itself) is vibed. A lot of that is probably aspirational.
to be fair, that's just the desktop client. You can use or build on top of the CLI
they do say they will open source it, but who knows:
"It isn’t open source yet—it currently depends on some proprietary components, including Epic’s internal design system—but we’re committed to open-sourcing it in the future"
There’s a “Repositories” link at the top of the page that links to https://lore.org/#repositories, WhyHow links to various GitHub repos, including https://github.com/EpicGames/lore, which claims to have code for the CLI. I see no reason to suspect that claim is incorrect. The code likely lives in https://github.com/EpicGames/lore/tree/main/lore-client)
I like everything I've read on this site so for, for it is also something I've been wanting.
If the roadmap's "Web client and code review tools" could replace gerrit for me, this would be a easy switch.
Moreover, it looks like they designed both the mutable store and immutable store to be able to easily store their state directly on an s3 like system.
There are a number of features that would greatly speed up CI/CD system operations I belive.
repo: https://github.com/EpicGames/lore
Looks very git-ish. But probably better equipped for large binary files.
I’ve always wanted a git with five commands, and maybe with AST based diffing
The five command part isn't really possible but you can use custom diffs for merges, git diff, etc. pretty easily. There are projects like diffsitter ( https://github.com/afnanenayet/diffsitter ) for doing more intelligent diffs like this for supported languages.
EDIT: and then an example for the merge stuff I couldn't find while typing before: https://mergiraf.org/ and HN discussion a few years ago: https://news.ycombinator.com/item?id=42093756
clone, pull, push, branch, merge, add, commit are the ones I use, but that's 7
I had wanted the same thing for a long time and jj + difftastic has satisfied me.
They’ve been dabbling in this space within Unreal Engine for a few years. Perforce is the de facto standard in AAA studios from my experience, curious to see what’s going to happen to them.
It’s great to finally see a possible alternative to Perforce.
Interested in this as perforce is pretty terrible a lot of the time
It’s like anything you do has to talk to the server
Even something as simple as diffing a file will just hang if there are server issues
this looks cool for game development, because using Git for projects in Unity and Unreal Engine definitely has it's issues. I'm personally not a fan of Git LFS, especially since GitHub charges you to use it (which makes sense, binaries and assets are big, code is small, relatively speaking).
Hosted onn GitHub. Heh.
Lore itself is not an example of a program that meaningfully benefits from any of the key features of Lore.
Lore is meant for situations where your repository is going to contain gigabytes of binary files, such as art assets for games. Git is technically great at everything but that, and even the external solutions for that situation still kind of suck.
Is Lore worse at managing text files, though? If not, it might make sense to adopt it fully in an organization so you can just use one tool.
This looks really good. I have been using git to store some PDF (tens of GBs) and git is really not well suited for this.
What makes lore better or worth considering... when svn and git never failed me...
Git does great with text files, but game development contains a lot of binary assets (textures, videos, 3d models) and correspondingly huge repos. git-lfs tries to patch around that, but that makes a complex tool that creatives struggle to understand even more complex. Perforce is a pretty popular solution, and was used by Epic in the past
Have to think they're doing this out of a real need, given they were already using Perforce and must've considered Git too. It's also not like 2010s when version control was a hyped thing.
> 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.
When you have a game that weighs in at 100GB, only a tiny fraction of that is built from code. The rest of it is binary assets that most VCSs struggle with. What makes this worth considering is the fact that they designed it to handle binary assets.
Apparently, how it handles binaries when developing games.
How long before Epic starts giving away other software and suing git to support lore?
I can’t remember the last time anyone actually played the game they got for free on epic’s store
Citizen Sleeper, the game that is going free tomorrow on the Epic store is really good. Space Cyberpunk themed RPG/Survival Sim.
It is interesting that people are so cynical about Epic giving out free games. I get that people love Steam, but competition in the storefront market is not bad.
I definitely have. But they're all the games that they gave out in the early days, the more recent games haven't really appealed to me. And it didn't convince me to spend any money, I still haven't spent a single cent on anything Epic Games.
Kerbal Space Program, Civilization 6, Hogwarts Legacy. All games nobody ever played…
I've been getting them for years now and have enjoyed many of them (though not a large percentage), and would love to use the Epic store more, if only they would implement some version of reviews/scores. Without that, I feel that I can't trust them as a marketplace.
I played hogwarts legacy for about an hour before realising it was boring, does that count?
I play Brotato fairly often. I am not sure I have played any of the other free games I’ve gotten though.
i've paid for brotato (Its a pretty good game, it was worth my money) and played city skylines (which i haven't paid for due to its excessive amount of dlcs)
They gave away Death Stranding awhile ago, and I hear that one is good, which I don't dispute given its Kojima origins.
But Kojima games require me to be in a very specific mood and I have been trying to work my way up to it.
Ahah, the second and third links on the page are to GitHub
Well it seems to be intended for repos with large blobs like video games so it kind of makes sense that their own pure source code is still managed with git.
It makes total sense. It’s just kind of ironic.
Epic's Unreal Engine development is made in Perforce, and then it was mirrored to git/Github. Or that's how it was a couple years ago. That's kind of expected, VCS is one thing, a forge is another thing.
Interesting to note that this does not seem like a DVCS in the traditional sense because it depends on coordinating with a central server where all repositories will be hosted. I can't tell if servers can pull/push from eachother.
What a waste of a phenomenal domain name.
My first thought exactly :(
I can't imagine it was cheap to acquire it, so any company with VC/big Corp money would've taken it any ways.
never trust epic
Their docs seem entirely LLM written. It seems especially obvious in the FAQ. While I'm not against using LLMs for writing assistance, they've left a lot of the unnecessary language and typical stylistic choices in there, which erodes my trust in the project a bit. Perhaps it's a very good game-oriented version control system, but the lack of human attention on the docs makes me wonder how much they care
I reluctantly agree. I was interested to read the system design doc[1] but it's so many pages long and so full of redundant statements and needless details[2] that I gave up a couple sections in. The numerous "it's not X, it's Y" constructions give the game away. If they can't be bothered to read these docs themselves, why should I?
Anyway it's probably fine software and I am genuinely going to give it a shot for a usecase I have involving large image files. But the LLM-generated docs don't inspire confidence.
[1] https://epicgames.github.io/lore/explanation/system-design/
[2] They literally have a section header "10.1 Revision state as a 320-byte fragment". The byte size isn't even relevant in the code as an implementation detail, much less belongs in a design doc. No one read this doc before publishing it.
Yeah, I agree about the docs. I started on the system design page and my head started to swim after about 5 minutes. So exhausting to read!
On the flip side, I expect the project itself will be workable - well, assuming they're actually using it themselves! UE is a big pile of Stuff on its own, and Fortnite must have god knows how much additional crap in there, so if this is (or will be) their replacement for Perforce internally, then it'll be getting a good deal of testing. (If they're just chucking it over the wall, though... well, sheesh, you first...)
(Perforce is the standard thing for games, and pretty well it works too, and hopefully this will deliver it a well-needed kick. It was sold to private equity about 10 years ago, and it feels like they've been coasting ever since. (Perhaps users in other sectors are happier though?))
Yeah, I hope I'm wrong, but it feels a little bit like "planned project no longer has internal support, let's see if we can make it open-source to garner goodwill and recoup some of our investment." Which isn't the worst thing that can happen.
The incredible laggyness of that website does not inspire confidence. Much of the text selection is also broken, and chrome consumes nearly a full core trying to render.. something?
Its remarkable that anyone thought this website was fit for release, and it gives off strong slop vibes
I also have absolutely zero trust in a product like version control being provided by a for-profit company. It seems like a terrible idea to tie your software stack to Epic Games of all people, given their track record
This is just going to become another way to lock developers into UE. Then they will start charging for licenses, same as Unity did for its versioning feature. It might be open source but that doesn’t stop the commercial use of it being charged for.