Ahah, the second and third links on the page are to GitHub
Lore – Open source version control system designed for scalability
51–60 of 717 posts
Re: Lore – Open source version control system designed for scalability
#52I'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?
Re: Lore – Open source version control system designed for scalability
#53Just 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 obje…
Git as a data structure is clever, but Git as a CLI is atrocious.
Still the porcelain is more like cold stainless steel
Re: Lore – Open source version control system designed for scalability
#54I'd trust this project more if it was named Data.
Re: Lore – Open source version control system designed for scalability
#55Their 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
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.
Re: Lore – Open source version control system designed for scalability
#56Earlier quoted context omitted.
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.
Re: Lore – Open source version control system designed for scalability
#57I’ve always wanted a git with five commands, and maybe with AST based diffing
Re: Lore – Open source version control system designed for scalability
#58Earlier quoted context omitted.
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."
Re: Lore – Open source version control system designed for scalability
#59I'd trust this project more if it was named Data.
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.
[0] https://en.wikipedia.org/wiki/List_of_minor_Star_Trek:_The_N...
Re: Lore – Open source version control system designed for scalability
#60Just 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 obje…
I’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push