Get the top HN stories in your inbox every day.
throw2ih020
LugosFergus
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 set something up with submodules, but that's going to upend your repository if you hadn't planned for it.
usrbinbash
> Something else that git isn't good at: permissions.
It doesn't have to be good at permissions. That's what DevOps platforms that integrate git are for.
MrDresden
I once worked in a git repository that required those kinds of restrictions.
This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it).
Needing to figure out a way to protect those parts of the codebase it was decided in the end that the "easiest" way of doing this was to split the repository in half, with the actual artifact building taking place from the half that had the NDA code. The rest of the application (basically the whole application) was then used as a dependency by it.
Still didn't quite solve the issue, but access to that repository was heavily controlled.
SoftTalker
Strikes me as bizarre that payment code would be sensitive, unless it's a security by obscurity thing (which would also be concerning).
Keys, secrets, etc. yes. But code? What am I missing here?
sroussey
PCI DSS has various controls for code handling credit card cards which tends to require different workflows for code that touches credit card numbers, from say, marketing pages. So splitting the code into different repos can be quite common.
yaur
Not sure what it is on the Apple Pay side but with FPLS it is/was basically your keys would be revoked and you would be ineligible to ever get new ones… so no content that requires DRM on iOS for the life of the company.
BobbyTables2
I assume compiling the payment code as a library (w/o debug symbols) and making that available to the wider group wast allowed? Header files a problem?
Meneth
Banks absolutely love security by obscurity. No clue why.
contingencies
Can confirm split repos is an excellent solution for protecting IP.
stevefan1999
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.
kccqzy
Git submodules aren’t convenient either. For the silo and corporate development use case, just use multiple repositories and make your build tool aware of multiple repositories. It is slightly less painful than submodules.
stackghost
I think everyone knows that this is a consequence of git's design. Nobody's disputing that.
Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.
Melatonic
That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering.
Does Gitlab do better with this?
wtetzner
I guess it's because git wasn't developed as enterprise software.
oneplane
How is it crazy? It's perhaps not granular (the repository is the boundary, and that's that), but you can definitely restrict who can pull or push as easy as you can make rules for SSH.
Plenty of not-very-granular "enterprise" systems out there, it's not exactly unique to not always have full ACLs on the smallest of objects.
pornel
git repos viewed through gitlab's slow Ruby monolith are still git repos, so it doesn't make any difference.
pid-1
No.
The maximum granularity is also 'per repo'.
yallpendantools
> Does Gitlab do better with this?
Not exactly but if you're not obsessed with maintaining a monorepo, Gitlab allows you to organize your repos around organizations, which then has granular permissions. The underlying primitives is still Git, of course, so you can just submodule as necessary.
1718627440
Because code is not supposed to contain parts that are secret or specific rules: those are data, that your program should work on. Git is coming from the open source movement.
anitil
Your comment and the parent comment are fantastic. I'd never have thought of them because I've never worked in the field
Freedom2
I ended up writing my own layer over git for permissions for a specific client a long time ago. It has a huge amount of useful features - sadly, I never took the idea further.
stogot
Turn it into a business
__d
Try gitolite?
https://gitolite.com/gitolite/index.html
It has fine-grained permissions but works with regular git clients.
LugosFergus
Does it actually restrict read access to specific directories? Unless I missed it, I didn't see anything in the docs about that.
iveqy
The way I usually solve this is by using git submodules.
bigbuppo
Oh man, I've been laughing at this for 37 minutes straight now.
contingencies
AFAIK the issue with using submodules is you still need the rights to pull the other source repo. However, you can use submodules or LFS to pull a specific build artifact from a build artifact repo or source instead of the source repo, which provides a neat way to manage the dep without fattening the main repo and allows the source repo to be kept separate and high security. I'd certainly do this before changing RCS/VCS solutions. That said, reverse engineering has become relatively trivial in the AI age so the practical utility of providing built rather than source elements is dropping.
bc1000003
Confirmed. Perforce is (was?) the industry standard for most larger game teams. If you've been in the business for any length of time you're probably pretty familiar with it and all of its many warts. But Perforce does get the job done and it's reliable and stable.
However combining some of the flexibility and workflows of git with the ability to deal more efficiently and effectively with large asset files is something that a hell of a lot game engineers would be interested in. And having the virtual checkout as a feature out of the box for folks used to half terabyte repo sizes is definitely a huge plus.
This announcement is definitely a big deal, and if the promises for lore actually measure up, we could be seeing the beginning of a switch over to open source version control for larger asset heavy games where git was still not a great fit.
Will be interesting to see what the public code hosting platforms do (github), and whether there will be any major structural changes to git (I'm thinking not likely). I wonder if Epic will make a play to take business away from github or gitlabs.
fsfod
There is work being done on Git to add pluggable object backends[1] by some GitLab devs that could changes things up a bit and make large object handling not suck Maybe Lore could act like a promisor remote to pull large objects from as well for interop.
maccard
> Perforce does get the job done and it's reliable and stable.
Well… perforce does get the job done, but it does need a lot of hand holding from an admin (and you need someone who knows p4 server if you’re using it). It’s also stable in the sense of “it has exactly the same feature set as it did 15 years ago, and branches (streams) are considered modern”.
arka2147483647
Its important to understand that in Game Dev a ’git clone’, aka ’p4 sync’, can be a terabyte of stuff.
Git is bad at such volumes of binary assets, textures, models, sounds, etc.
cylemons
Yikes, does that mean each dev has terabytes of stuff on their machine?
badsectoracula
Theoretically yes, but in practice you don't need the full repository, but even in mid-2010 (when i first encounter Perforce in a gamedev company - previously the companies i worked on used Subversion which was also able to handle some huge repositories -- one had all their games from the 90s to early 2010s in a single Svn repository, including code and data) a workspace with just the game's code and data in the engine's format (i.e. excluding everything a programmer wouldn't need, like the "source data" for assets such as max/maya/etc files) was around 250GB or so. IIRC the entire repository (all versions, not just latest) had crossed a petabyte in size :-P though that company put absolutely everything in Perforce.
raincole
One thing I don't like about Git LFS is that there is no way to delete very old history. It's the 'git spirit' to not allow deleting history, but in the context of LFS it sounds horrible. Especially if you use Github.
If there is an asset that is updated very frequently in the early stage of development, you'll be charged for all the storage for the rest of the repo's life. That happens a lot in gamedev: most assets go back and forth early on but once it's done no one will touch them ever.
Marsymars
> One thing I don't like about Git LFS is that there is no way to delete very old history. It's the 'git spirit' to not allow deleting history, but in the context of LFS it sounds horrible. Especially if you use Github.
At my dayjob we used Git LFS for a bit, but foud it unworkably clunky - we eventually found it easier to just make a separate "LFS" repository and add it as a submodule to the main monorepo. Now we can rewrite the history of the LFS repo on an as-needed basis.
fc417fc802
> Now we can rewrite the history of the LFS repo on an as-needed basis.
With the giant caveat that doing this effectively breaks the history of the parent project. TBF that's not really any different than rewriting history and later discovering that an old version of a lockfile no longer works but I still think it's worth mentioning.
a1o
I think you can delete the history but it’s hard (more than three steps), at least that was my conclusion from the e blogpost below
https://janetgilbert.net/staging/2026/04/27/dealing-with-old...
paulddraper
> that there is no way to delete very old history
That's one of the features of Git LFS is separately managed storage and lifetime.
You are correct that GitHub does not offer that feature.
doctorpangloss
Git LFS is unusually bad. I think the maintainers are trying their best but it is one of those things where there are so many bugs and so many users that they will claim they are overwhelmed with LLM authored PRs instead of conceding that they own a very valuable piece of real estate (being installed alongside git by default) and totally mismanaging it.
foobarchu
LFS is not installed by default alongside git, it's a separate package in most systems
jayd16
P4 is more "industry standard" than "state of the art"... But it does handle large files and partial checkouts without feeling bolted on.
manoDev
Git LFS is a major PITA, and if you use GitHub is even worse since there are quotas and rate limits that are charged separately.
ifwinterco
One of those ideas that sounds clever in theory but in reality doesn’t work very well
bigbuppo
Also... it's kind of weird taking a decentralized system and recentralizing it.
undefined
debarshri
I am building a small asset heavy game. Ran into a similar problem. Built a storage cost efficient tool for exactly this [1].
j1elo
There's also the virtual streams (branches). A mapped overlay over the actual contents of the repo, which you can check out and get a subset of the contents. Or even can provide different files that have been mapped in the server for each particular virtual branch.
This is used so e.g. an artist gets a repo that contains sources for the art assets, while a programmer gets the same repo but instead of art sources, it downloads the already produced binaries. As a SE, you just want to build the code, and don't care about 800 GB of art asset sources.
niek_pas
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.
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 maine40
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.
foresto
> It's probably just something no one has thought of doing.
One might reasonably think that about a number of git's rough edges, and one might be surprised at the reality.
Some years ago, the annoyance of git's inconsistent terminology drove me to look into consolidating "cache", "index", and "staging area" in git's help text and documentation. What I found was that others had (of course) thought of it before, but when they tried to do it, it was rejected by git's gatekeepers.
throw_await
That makes me sad. This termainology is really one of the major flaws of git, along with the checkout/reset thing
js2
I understand there's friction in contributing to git, but it's absolutely possible to improve the docs:
Contributions from jvns:
https://github.com/search?q=repo%3Agit%2Fgit+jvns&type=commi...
Here she explains how she did it:
https://jvns.ca/blog/2026/01/08/a-data-model-for-git/
Contributions I've made:
https://github.com/search?q=repo%3Agit%2Fgit+jaysoffian+docu...
Generically:
https://github.com/search?q=repo%3Agit%2Fgit+documentation&t...
Do you have a link to your proposal on the git mailing list?
Melatonic
Are those three really all the same things? That seems crazy to have all three not consolidated.
maccard
> 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.
yoyohello13
Luckily it’s an open source project so you could go in and clean up the ux.
1718627440
I do want a progress indicator for something that might take a while without asking. If you clone things locally, Git only reports that it cloned something.
js2
Objects are your files. Underlying git is a content-addressable filesystem.
The objects are referenced by trees. A tree is just a directory.
The trees are then referenced by commits and/or tags into a DAG with named pointers into various parts of it (which are your branch and tag references):
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Because it would be terribly in-efficient to have a bunch of loose objects, git periodically groups them together into packs. To save space, the objects are compressed against one another (delta compression) within the packs.
https://git-scm.com/docs/git-pack-objects
https://github.com/git/git/blob/master/Documentation/technic...
When pushing or pulling, the git transfer protocol basically enumerates what objects each side has so that it only needs to transfer the difference. On top of that, it delta compresses the objects on each side that aren't already grouped into packs against each other to save space.
https://github.com/git/git/blob/master/Documentation/technic...
Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!
But if you really want to know, it's all documented both in the git book and git documentation directory, both linked above.
(Caveat: I'm working from memory and surely got some detail at least slightly wrong.)
sundarurfriend
> Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!
This is the type of attitude that kept most Unix tools quite user-unfriendly for several decades. What information to show the user, and when, are important design decisions to make. Just dumping it all on the user and making them wade through it is not doing the user a favour. Thankfully newer tools seem to be better about this, which has brought the Unix shell forward by leaps, even if there's still ways to go. (You can still make a conscious design decision that the info needs to be all there, and git is one of tools where that's at least somewhat justifiable, but a lot of the time the attitude is more like in the quoted text, that dumping out more info is always better.)
js2
> This is the type of attitude
This is the type of attitude that makes me regret ever commenting on HN.
FFS, git is a tool for programmers.
dansmith1919
The point is that if it's useless information for 99.9% of users, what's it doing in the UI?
1718627440
A percentage information for a network upload is very much not useless information. In fact making the user wait without any indication of progress is very bad UX.
js2
It's not useless information, any more than the tachometer or a temperature gauge instead of an "idiot light" in a car is useless information. Again, "because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!"
If you don't want it, use `--quiet`. I like that it's there by default since it's useful when I need it and ignorable when I don't.
Of all the things to complain about git...
genocidicbunny
Now explain this to an artist with very little programming experience beyond what they picked up from their coworkers.
I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them.
I worked in gamedev, and many of my colleagues were brilliant, but your comment would read as complete nonsense to many of them. That is the problem git has in the gamedev space. You're trying to manage teams of programmers, designers, sound engineers, gameplay specialists, producers...even c-levels. The parent comment to yours is right, to many many people who work on things that Lore could be useful for would find git to be gobblygook.
js2
I'm not here to engage in rhetorical combat.
I was simply answering niek_pas's rhetorical questions, that's all, because maybe they piqued someone's curiosity and I can contribute a little of my esoteric knowledge about the inner workings of git. This is a site for the curious, yes?
Git is a tool by programmers for programmers. If folks outside the programming community are able to use it, great, but that's not its target audience. You don't need to convince me why git isn't suitable for artists.
Cheers.
qwery
git is not a particularly suitable VCS for gamedev for reasons so much deeper than what messages it prints for a given command. git is a tool built to solve versioning text files in a collaborative, open software development context. That is the problem git has in the gamedev space.
1718627440
It's a progress indicator. Everyone has had the concept of percent in school even if they are an artist.
jen20
> I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them.
Git is a software development tool first and foremost to support the development of an _operating system kernel_. It's perfectly reasonable for it to be technically verbose as a default, in the same way as it's reasonable for a band saw to cut off your finger if you use it without understanding things correctly first.
The problem git has in game development is not that the output is too complex, it's that it doesn't handle large binaries well (ironically enough, the focus of the replacement system in TFA).
mariusor
Your straw man artist should use any of the nice frontends that work on top of git and hide its verbosity.
anigbrowl
Respectfully, I think you're missing the point. The GP is not asking for an explanation (and could look that up from the Git docs) but commenting on how user-hostile it is. There's lots of software like this, which is so unfriendly that once you've learned the minimum of how to do something and verify it worked, you don't want to touch it any more unless you really need to.
CLI output should be in plain language and omit or minimize unnecessary detail absent a -verbose flag - for example, I'm just not interested in how many threads something took unless I'm working on it. As a user, I want to be focused on the task I'm doing, not on the perfromance of the tool.
Melatonic
I dont think the problem is even verbosity here - it really isnt that much text.
The issue is what you and the above points out - it is not easy to read.
What might help dramatically is a simple modification of text (the verbose stuff could be slightly light grey and the important bits fully highlighted white) or even go full IRC with colored text, bold, etc.
Or hell - maybe instead they add a switch that inserts "//comment" like additionally lines to explain what is going on (succinctly) to the average Power User type. The default could be "software engineer" mode and the switch enable "Git for Dummies" mode.
mvdtnz
Do you know what a rhetorical situation is? Do you understand that the parent was not actually seeking answers to these questions, but was using the questions themselves to make a point about the Git UI?
qwery
I think your criticism of git's output is fine -- fair enough.
What I will say to that directly is that everyone's different and expecting a UI to match every user perfectly is unreasonable. I don't think it's fair to call output that's more verbose than you'd like "user-unfriendly" without qualifying who the user/s is/are.
The thing missing from most of the responses to this is: you can only get this information once. It's effectively impossible to have any of this information repeated -- you can't run it a second time with `--verbose`.
I don't mind things telling me what's going on, and git's push output is perhaps verbose, but not by a margin that causes me trouble. Maybe that comes with always running less than ideal hardware and having second rate internet connections. I want to know why a command took longer to run than I expected.
y1n0
I’ve started using JJ vcs, mainly because some people were saying it was great and I didn’t really get it.
I’m starting to come around though. From a UI perspective it’s a major improvement on git. The branching workflow is something that has taken a bit to get used to though.
lkjdsklf
Jj is weird. In general it’s a better ui and model than git, but there’s a few common operations that are just dumb.
It also recreates a lot of the stupidity of mercurial (which makes sense)
The fact that everyone needs the same stupid “tug” alias because jj wants to use “bookmarks” instead of just named branches is just classic silly shit.
We’ve had named branches for 40 years. Everyone who has vcs experience knows what it is. We don’t need bookmarks. Just stop. Everyone who used mercurial used plugins to turn them into basically branches and same thing with jj.
y1n0
That's built in now, for what it's worth.
BatmanAoD
I honestly get the sense that several, or possibly most, jj maintainers truly are not familiar with the "typical" way devs use git. They really do not seem to consider branches with many commits to be a common use-case.
squirrellous
The last time I tried JJ it plainly refused to work with git LFS, which is kind of what OOP here is about (large files). Has that improved?
spelunker
The lights are blinking, so everything must be working!
russdill
Basically, sometimes there commands take a long time. It's nice to have feedback that something is happening even if it's just effectively a blinking light.
dosshell
Every place I worked at has a git introduction where all new employees learn about how git works internally. Takes 1h, and all junior devs stops memories random commands and actually start to understand. I highly recommend to you to poking around in the .git directory.
The git support for new employees drops basically to zero.
agumonkey
I actually like this underlying logs. Could have a concise / project level summary though.
kristjansson
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
tlahtinen
This is a very promising announcement for Unreal game development specifically. For any other purpose I wouldn't care as much.
Perforce definitely needs a challenger. It is not the incumbent because it is particularily simple to use or administer. Git is actually way simpler when it comes to branching operations for example.
The reasons why p4 is often preferred in gamedev have already been mentioned in other comments: large project support, permissions, file locking and so on. Another key reason p4 is the king for Unreal dev is just how well it's supported inside the engine. Not perfect, but it's the best supported VCS because it's what Epic uses. Even the Git plugin is painfully unfinished, because Epic does not internally use it. So with Lore I expect them to give it first class support. I'd recommend Git a lot more if the support in Unreal was better.
(background; I've been in gamedev for almost two decades now, 2-200 person companies, every kind of engine and version control system. I prefer git where I can use it: for Unreal that means small projects and/or tech savvy team members. Pick the tool that is right for the job and the team.)
jayd16
For what's it's worth I've been brushing up the plugin a bit. The odds of it getting merged in are even less likely after today, tho.
undefined
boppo1
What about blender?
akurilin
We had to use Perforce (Helix Core Cloud) at my last game studio, and it is the de facto industry standard that most of your creative staff is already familiar with. The programmers don't love it, but they don't rule the roost in games. It's also the safe, verified default for working with Unreal Engine 5.
It does show its years though. We were one of the first users of the Perforce cloud offering, as we were small and didn't want to self-host ourselves, but it was a bit of a rickety experience. You had to register an Azure account in order to be able to access the service, and you had to ask support to modify things like triggers. Coming from the world of GitHub and other SaaS products, you could tell it was an attempt to retrofit an older model into a new skin.
The Git LFS path has some unofficial support as well, but you are on your own when things go poorly. Epic doesn't provide much help there.
Competition in this space is welcome, especially if they're planning to make it fully officially supported by the Engine.
I wrote about why merging files isn't as common in the world of game dev for folks coming from the world of text: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
dijit
ditto; and UE5 on anything that isn't perforce is a lesson in pain.
I just took over a team that was using Git, and yes, I know it's everyones favourite VCS but for Games it's just about the worst thing available. I could measure art reviews with git in hours, now with perforce its seconds. I wish I was joking.
All the interesting tools that UE5 uses (Horde/UBA for a clean example) will require perforce.
but, Perforce hasn't done anything with its industry position. It's expensive as hell and they don't have operational costs related to hosting (you have to host it yourself, and honestly, for performance reasons you really want to- despite it being a real pain to maintain passed first install). There's some echoes of stuff they try but they have absolutely no solid direction and nearly everything they've been doing cuts against common sense or their userbase, while their core product keeps getting renamed but no actual improvements.
It's a lesson in how proprietary software is really a prison.
I wish I could use a better code review tool than Swarm.
I wish I could integrate SSO without weird LUA hooks which cause segfaults on my machine (enough of them causing a perforce deadlock).
and I wish I could run a distributed storage backend instead of relying on a big fat SSD and journalled backups that can't be restored because licenses are tied to the IP address of the main server.
It's forgotten technology, and the company that operates it is a zombie.
maccard
I completely agree with every single point you've said here. Running a P4 server is an exercise in self torture, but it's the only option with UE5.
> I wish I could use a better code review tool than Swarm.
With one caveat. I think swarm is a great tool. It could do with being easier to configure, but as a code review tool it's simple, straightforward and gets the job done.
> I wish I could integrate SSO without weird LUA hooks which cause segfaults on my machine (enough of them causing a perforce deadlock).
this is about the only thing that Perforce has actually managed to do in the last... 5 years? [0] It's also woefully awkward to set up and operate, as is everything P4. But it does work.
[0] https://help.perforce.com/helix-core/integrations-plugins/he...
dijit
I'm actually using helix-authentication-service.
Swarm "works with it" in theory, but in practice I had to patch the loginWithSSO function to shell out to the p4 process to handle auth, because P4PHP doesn't expose ClientSSO at all and it's required for a clean login with keycloak.
EntraID is a different flow that they've probably nailed, from what I hear from other studios.
akurilin
Couldn't agree more. I wonder why the company stalled as much as it did. To be fair they've been around for three decades, maybe it's just hard to keep momentum for that long, especially if you're in a dominant position with no competition coming after you.
tom_
They got sold to a private equity company in 2016.
jayd16
UBA mostly doesn't need Perforce and Horde isn't as good as the GitHub, gitlab etc.
UGS (the tool that pulls down the latest engine version for artist) is pretty perforce centric.
dijit
Wasn't aware that Gitlab could do distributed compilation.
Horde configurations can only live locally or in Perforce: https://dev.epicgames.com/documentation/unreal-engine/horde-...
Horde only supports Perforce today: https://dev.epicgames.com/documentation/unreal-engine/horde-...
UBA and Horde go together pretty well- in fact I've never seen a distributed-UBA deployment without a horde one (SN-DBS, Fastbuild or if you're wealthy: incredibuild are much more popular), but adaptive unity builds check for a read-only flag; which is how Perforce treats checked-out/changed files but not git.
superxpro12
Git LFS and git's (relatively) new sparse clone features i suspect are their answer to this sort of thing, although my understanding is that was more focused on monorepo operations in general. I'm not entirely sure permissions were sorted, or this sort of mixed-mode dvcs/cvcs operation model with file-scope checkouts interacting with traditional branch-mode operation.
ex-aws-dude
Its not just about the tech, you have to have non-technical artists using this thing every day
munificent
I really like your article. It does a good job of explaining not just the technical differences but the way those affect the surrounding development culture.
akurilin
Thank you! It was a bit of culture shock for me when I first experienced it, coming from the world of business software, and I figured others would find it equally fascinating to learn more about.
munificent
I went in the other direction. 8 years at EA and now at Google working on open source.
Everything is so easy when your entire source repo is a paltry few hundred megs and you can build everything from source in a few minutes. It feels like flying.
ksec
Turns out it is not really new but only open sourced it now. From the FQA.
>Lore, formerly called Unreal Revision Control, is the built-in version control system for UEFN (Unreal Editor for Fortnite), where creators have been using it to version their islands. It is also seeing progressive adoption by internal Epic teams, and is being implemented as the backing store for UEFN’s cook pipeline, where it replaces traditional intermediary storage layers—eliminating redundant file transfers and significantly reducing the time between publishing changes and those changes being playable.
Surprised it is in Rust and not Epic C++ or Verse. I wonder why.
wrwills
I suspect the use of Rust rather than C++ might have something to do with the fact that Simon Peyton Jones and Lennart Augustsson (both of Haskell fame) both work at Epic and there would have been a strong internal push to do this in a language with some functional programming features. Rust rather than Verse because that would probably not be the right tool for the job (even if Simon works on it). Rust rather than Haskell probably because of performance -- DARCS never caught on partly for performance reasons.
frollogaston
I don't see how Rust is more functional programming oriented than C++
MaulingMonkey
C++'s stdlib collection algorithms were basically all mutate-in-place instead of return-a-new-value until C++20 introduced ranges, and I still don't know anyone who actually uses those. By contrast, people actually use the `container.iter().map(...)` etc. in Rust.
C++ also lacks much of the fancy pattern matching features which are frequently associated with functional programming. Such features may not be fundamental to functional programming, but they would fall under "some functional programming features", in the sense that they're common in the languages of that ecosystem.
wrwills
I think the things that make Rust safer than C++ make it look more like a functional programming language than C++. The main point is that there are some influential people at Epic (SPJ has often spoken favourably about Rust) who would favour it over C++.
k_bx
Pure by default, type classes (traits), no inheritance, type level lifetime computation. It's not only more functional it's much more type-safe and closer to Haskell in spirit
IshKebab
Rust has a load of FP-style iter/map/filter stuff that you can technically do in C++ but only if you don't mind bleeding eyes.
It also borrows a lot of features from FP languages like nice tagged unions (enums), Result, everything-is-an-expression, etc.
LugosFergus
It's a separate tool from Unreal Engine, so you don't need to constrain yourself to its conventions. You're also not going to use UObjects, its reflection layer, serialization, and all that other stuff for a tool that's strictly for version control. Plus you're going to tie yourself to all the issues and slowness of the engine. Epic made this mistake with the Epic Games Launcher, which is essentially an instance of the engine running, and a huge source of various issues.
As for Verse vs Rust, Verse is used in UEFN experiences, but it is _far_ from any kind of production state. It's also intrinsically tied to UEFN. It's not like you can download a standalone compiler or REPL for Verse.
yjftsjthsd-h
Honestly it inspires rather more confidence in me to see a tool that has actually been used for a while and is just now being released for public use as well. Unless, of course, it's being released because they've decided to stop development, but I don't think that's the case here.
jacobgold
I'd trust this project more if it was named Data.
HansHamster
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...
manifoldgeo
If it were Data instead of Lore, it would reject any commit messages that used contractions such as "I'm" and "can't" ;-)
zdw
Dunno, this seems fully functional?
CommanderData
Oh brother.
Don't be too hard on Lore.
analog8374
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.
falcor84
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...
zdimension
Oh, so that's why JetBrains data thing is called DataLore. TIL
cwillu
an evil brother
frollogaston
What is this, the sequel to the evil Spock with a beard?
analog8374
As is my reply.
(Trek) Data is Lore constrained to, what? Convention?
testdelacc1
The likely source for Lore - https://memory-alpha.fandom.com/wiki/Lore
superkuh
"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.
VibrantClarity
I haven't played it since the buyout either, but I'm told it works perfectly with Proton.
LoganDark
You can no longer use Proton on a Mac (unless you have one of the few models supported by Asahi)
superkuh
Yes, running the windows version of Rocket League might be possible. But that's not what I bought.
stronglikedan
> They stole from me and many others.
It's more likely that they took advantage of some things in the license that you weren't aware of, since stealing would be illegal.
Zardoz84
Could be legal, but it's un ethical
penciltwirler
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!
LtdJorge
I don't think the needs are exactly the same. I believe in AI the big binary files are normally written once, while in gamedev, they are constantly updated.
That already warrants different storage architectures.
dimatura
There's also git-annex and iterative DVC. I used xethub a fair bit (was the earliest user, in fact) and I thought it was better than git annex, git-lfs and DVC, but still did start to struggle past a certain size. I think part of the problem was just git itself, and the compromises required to have a hybrid repo. So I'm happy to see this vcs doesn't use it. xethub did start shipping a version of their product that did not use git but I didn't get the chance to try it. I've also tried oxen and it wasn't bad at first, but soon ran into some weird issues with the repo state which I didn't really try to debug. It is clear to me at this point, given my experience with all these systems -- none of which I've been 100% happy with -- that "git for data" is a nontrivial problem.
ozkatz
Curious if you’ve had a chance to try lakeFS?
It was designed with large-scale environments in mind. I’m aware of several deployments managing hundreds of petabytes of data and billions of objects, which is why lakeFS does not use Git’s Merkle tree / directory tree approach.
Disclaimer: I’m one of the project’s co-creators.
gschoeni
one of the oxen engineers here would love to hear about anything you ran into on the os product or platform! we've grown the team a bunch and are eager to learn what your perfect vcs looks like
undefined
bschmidt900
[dead]
calebm
Any lore hosting services available?
minton
I know this is targeted at game dev, but I wonder if this would work well for a huge MS Access app.
frollogaston
"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
ibejoeb
I don't know if it's a jab at git. Git does have `porcelain` to accommodate programmatic interaction. It's not linkable, but it's still an API.
iceweaselfan44
>fully open source >look inside >Lore Desktop Client is available as binaries only, download the installer for your platform here:
O5vYtytb
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.
Wowfunhappy
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.
adastra22
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.
lentil_soup
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"
KomoD
> to be fair, that's just the desktop client.
I expect fully to mean fully, though.
Someone
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)
pkasting
The idea sounds good, even if Epic's recent track record of tools is not inspiring. But the commit messages etc. are very clearly products of vibe-coding. And version control is not the situation where "works 97% of the time" is a good-enough bar.
Passing for now.
frollogaston
About the recent track record, is there some technical problem or just drama with Unreal Engine that I'm not aware of? (I already have the same opinion about using AI-coded VCS.)
Get the top HN stories in your inbox every day.
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.