Rendered at 02:41:36 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
throw2ih020 12 hours ago [-]
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.
LugosFergus 11 hours ago [-]
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.
MrDresden 11 hours ago [-]
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 10 hours ago [-]
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?
danudey 10 hours ago [-]
As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time.
See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling a joint demonstration of the Radeon card that was going to be in the system, and never partnering with ATI again.
From the linked article, it was a press release, not just to his employees.
> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.
danudey 7 hours ago [-]
Oh, I misremembered then. Yikes.
ifh-hn 9 hours ago [-]
Sounds like a bit of a dick...
therealpygon 3 hours ago [-]
For violating an embargo and publishing a press release announcing products of another company that hadn’t been debuted? What “non-dick” response do you think is appropriate against a prospective partner that violated clear guidelines that defined their partnership which basically included “#1: Keep your mouth shut”, exactly?
rib3ye 8 hours ago [-]
Going scorched earth was kind of Steve’s thing.
MoonWalk 4 hours ago [-]
He was, but this incident wasn't an example. That's a righteous punishment for an infraction like that.
paulddraper 8 hours ago [-]
They unilaterally issued a press release about Apple's upcoming release.
That's kinda a no-no for partnerships.
yonatan8070 9 hours ago [-]
One word: "Courage"
ifh-hn 8 hours ago [-]
Not sure I understand? Sounds like a temper tantrum to me.
kenferry 7 hours ago [-]
Inside joke. Apple's marketing guy used the word "courage" as an explanation when removing the headphone jack.
RajX-dev 50 minutes ago [-]
lol
LPisGood 4 hours ago [-]
That decision had a lot of detractors at the time, but it ultimately seems to have been correct.
m463 2 hours ago [-]
I don't know if I agree.
People who moved to bluetooth got arguably worse sound quality.
For wired headphones, there were very few lightning headphones and they mostly sucked.
Now with usb-c you can get a broader range of headphones (because other phones have gone with usb-c).
either kind needs a dac inside the dongle, or the shell of the headphone, or have a bulky external dac.
3.5mm is still king for decent wired headphones/earbuds.
jianfenglin 7 minutes ago [-]
Most people don't like wire and don't care about genuinely good sound through wire vs. artificially sweetened (DSP-ed) sound through Bluetooth. That's what Apple is targeting at, the mass consumer.
_carbyau_ 2 hours ago [-]
It still has a lot of detractors but it is hard to beat such a sheer market flex.
MoonWalk 4 hours ago [-]
Four words: You're holding it wrong.
formerly_proven 9 hours ago [-]
> and never partnering with ATI again.
Except of course shipping ATI hardware for years afterwards, then also using nvidia, then dropping nvidia and only using ATI/AMD until transitioning to Apple Silicon.
danudey 7 hours ago [-]
Well:
1. They kept existing designs, since even Jobs wasn't so crazy as to demand a complete re-architecture of existing laptop models on a whim; plus they probably also had contractual obligations/pre-purchase arrangements
2. They switched to nvidia, but from everything I know they also hated working with nvidia (IIRC Jobs accused nvidia of stealing Pixar tech)
3. AMD is a different company than ATI (technically), and Apple of that era was different than the Steve Jobs temper tantrum era.
But yes, relevant details.
NewJazz 8 hours ago [-]
Also Steve Jobs Apple is probably much different than today's Apple.
isodev 6 hours ago [-]
It’s funny how exciting Apple Pay was when introduced, only Apple pulled the lock-everyone-in card and now we’re all using QRcodes.
mixdup 4 hours ago [-]
In the US you can use Apple Pay anywhere NFC payments are accepted. It's generally completely open on the acceptance side at this point
josephg 2 hours ago [-]
[dead]
ZekeSulastin 5 hours ago [-]
I guess the "we" depends strongly on location - I've no problem using Apple Pay basically everywhere except Walmart.
MoonWalk 4 hours ago [-]
No idea what this is referring to...
NetOpWibby 5 hours ago [-]
SHEESH
edoceo 5 minutes ago [-]
There is a bunch of mundane stuff in the banking/finance world masked off by paperwork.
It's not sensitive in the leaking state secrets sense it's sensitive in the risk adverse lawyers on both sides think it's sensitive.
The Bureaucracy exists to perpetuate the Bureaucracy.
kazinator 3 minutes ago [-]
[delayed]
kurthr 10 hours ago [-]
Because it's Apple. They are huge, have scary lawyers, write scary contracts, and want to "delight the user" with features only when they announce them. They hate leaks, and demand separate teams for basically any/all development.
HWR_14 7 hours ago [-]
The code revealed the existence of Apple Pay, which had not been publicly confirmed.
user_of_the_wek 9 hours ago [-]
It seems this wasn’t about the code itself, it was about Apple Pay not being announced yet. So only people under NDA would be allowed to even know what they are working on.
It's kinda like that, there could be a proprietary fraud detection heuristic in there that you don't want to get out.
zer00eyz 10 hours ago [-]
> security by obscurity thing... What am I missing here?
You are looking at the problem from the wrong direction.
If you build a honeypot, to trap hackers, does it behove you to explain what the bait is, and how the trap works?
Know your customer, fraud detection heuristics, finger prints, behavioral triggers are all areas where banks, and financial institutions need to keep the sauce secret. Telling the other party "how" you catch them just gives them the steps of what not to do.
hk__2 10 hours ago [-]
Maybe that’s some scoring to decide if you should be able to pay or not with some method.
sroussey 7 hours ago [-]
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 8 hours ago [-]
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.
Meneth 5 hours ago [-]
Banks absolutely love security by obscurity. No clue why.
jeremyjh 5 hours ago [-]
It had nothing to do with security - it had to do with contractual obligations. Contracts with Apple (also Google, Samsung, Mastercard and Visa) required the product to be kept absolutely secret before the public launch. I was a tech lead with developers working on Bank of America’s ATM client - which had firmware and software updates ahead of launch - and I found out about Apple Pay the day it launched. Across the aisle were developers who supported the debit auth platform and they had no idea either.
vorticalbox 5 hours ago [-]
security by only obscurity is bad. Having both is better.
For example say I have a hollowed out wall that is hidden behind a painting.
Just putting my money in the hole is bad once it’s found it’s gone but if I put my money in a safe in the hole. Well now you need to find it and break the safe and a hidden safe is objectively better than just having a safe on the floor because you need to find it first.
mvkel 5 hours ago [-]
It's the most effective kind of security
contingencies 9 hours ago [-]
Can confirm split repos is an excellent solution for protecting IP.
anitil 16 minutes ago [-]
Your comment and the parent comment are fantastic. I'd never have thought of them because I've never worked in the field
Melatonic 8 hours ago [-]
That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering.
Does Gitlab do better with this?
wtetzner 8 hours ago [-]
I guess it's because git wasn't developed as enterprise software.
yallpendantools 4 hours ago [-]
This. People forget a lot of Git's design philosophy harks back to the ethos of open source development. Enterprise features have made it in over the years but still mostly with the FOSS development workflow/model in mind. Also why the most enterprise-y of features (like LFS) are add-ons rather than core.
m463 2 hours ago [-]
Maybe you could go to linus and demand enterprise features and support.
;)
oneplane 7 hours ago [-]
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 7 hours ago [-]
git repos viewed through gitlab's slow Ruby monolith are still git repos, so it doesn't make any difference.
yallpendantools 4 hours ago [-]
> 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.
pid-1 7 hours ago [-]
No.
The maximum granularity is also 'per repo'.
1718627440 4 hours ago [-]
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.
stevefan1999 11 hours ago [-]
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 11 hours ago [-]
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.
packetlost 11 hours ago [-]
I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.
InitialLastName 6 hours ago [-]
That and a way to recursively commit/push (i.e. make a change within a submodule, commit in one step with the same message in the parent submodule).
Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to:
1. Change the file
2. Commit within the submodule
3. Push the submodule
4. add the submodule change in the outer repo
5. commit in the outer repo
6. push the outer repo
1718627440 4 hours ago [-]
You can combine the push step. A submodule intentionally follows a different development/commit/version cycle, otherwise you are supposed to use a subtree.
1718627440 4 hours ago [-]
You can set submodule.recurse to true and then git commands operate as if you passed --recurse to them? It's just that most people don't actually want that, because a submodule is generally something you intentionally want to handle separate.
a1o 5 hours ago [-]
git submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.
Orphis 4 hours ago [-]
To add to this, you can add in your .gitmodules the name of the branch that the --remote flag will follow. It just works.
joshy324 5 hours ago [-]
[dead]
1718627440 4 hours ago [-]
Submodules ARE multiple repositories. This is not an either or.
kccqzy 2 hours ago [-]
I understand that. I am just arguing that making your build tool aware of multiple repos is enough; no need to use submodules in git and make your build tool pretend to operate on a single repo.
stackghost 10 hours ago [-]
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.
PaulDavisThe1st 6 hours ago [-]
And a few of them think that it is corporate structure and development models that are actually the problem.
I'm just asking questions!
stackghost 6 hours ago [-]
I don't understand what you're trying to imply.
If you're making the point that there are multiple confounding factors to just about any non-trivial problem, then I agree.
PaulDavisThe1st 5 hours ago [-]
No, I'm making the point that the way in which git doesn't fit well into many corporate processes can be interpreted as more of a negative commentary on those processes than on git.
I said read access. The point is that there’s restricted information that only some can access.
Freedom2 10 hours ago [-]
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 8 hours ago [-]
Turn it into a business
iveqy 10 hours ago [-]
The way I usually solve this is by using git submodules.
bigbuppo 9 hours ago [-]
Oh man, I've been laughing at this for 37 minutes straight now.
orthoxerox 9 hours ago [-]
Git submodules are the regular expressions of version control.
zephen 8 hours ago [-]
When you use regular expressions, you now have two problems.
When you use git submodules, you now have five or six problems.
SCLeo 3 hours ago [-]
And every PR turns into a triple recursive reverse merge.
contingencies 9 hours ago [-]
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.
Jare 8 hours ago [-]
You'd have the non-NDA, core stuff in the submodule. The submodule can then be referenced by the big, driving NDA repo. And maybe another repo with a non-NDA, likely simpler "shell" that lets non-NDA devs work with the codebase.
If you need to NDA the core stuff instead and thus can't pull it as a submodule, the only thing I can think of is to pull the core as binary/compiled artifacts.
odo1242 8 hours ago [-]
You can set up submodules to not pull the other source repo by default tho
PunchyHamster 10 hours ago [-]
> That's not something that you can do in git: it's all or nothing.
That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules
jmaw 9 hours ago [-]
Does `--no-verify` override the restriction via hooks, or are there some kind of server-side hooks that can be used?
PunchyHamster 6 hours ago [-]
no-verify cancels local hooks, remote hooks are unaffected.
Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.
hhsecurity 8 hours ago [-]
My teaspoons are terrible at peeling potatoes.
Git has no built in authentication or RBAC. Thats not what its for. Its flat file source control.
I swear loads of people havent a clue how git works or why it exists...most of the git based cloud services out there are 90% additional crap bolted on.
cdmckay 8 hours ago [-]
I think that’s the point of the OP. Git is great at certain things but is not a one size fits all.
francislavoie 8 hours ago [-]
Obviously, and that's why tools like perforce and lore exist. What's your point?
Arainach 7 hours ago [-]
Perforce predates Git by a decade (but your overall point is valid)
fartcoin67 8 hours ago [-]
My hackernews is terrible at reading, nobody said any of that shit
charcircuit 8 hours ago [-]
>Thats not what its for.
This is a weak argument you could use for any missing feature.
1718627440 4 hours ago [-]
But it's more like a fundamental design choice.
rowanG077 11 hours ago [-]
Doesn't git crypt solve this? You can have encrypted blobs in a repo that will be auto decrypted if you have a working key.
danudey 10 hours ago [-]
That depends on you distributing working keys for any components you want to restrict access to, and managing those keys for all users, revoking them when access permissions change, etc. It's a lot more complex, more work, and harder to manage than centralized RBAC or similar.
giancarlostoro 11 hours ago [-]
People don't use git crypt nearly enough unfortunately.
freedomben 11 hours ago [-]
Agreed. I use and love git crypt, but it doesn't get enough use. I think because it's easy to screw up gpg keys. Most of my uses (for one to three devs) have become symmetric keys shared out-of-band instead of using gpg keys because we've had lots of onboarding pain even from people who are quite competent. There are just a lot of sharp edges in gpg that you don't know when you don't know.
everforward 10 hours ago [-]
Not really, precisely because it’s decentralized. You can’t audit whether a user accessed one of the hidden files, or really even who can access it once you accept the reality of the risk that some team will put a key on S3 or a shared drive or whatever.
It’s fine for things that you want devs to be able to see without the Git host being able to see them, it’s less good at RBAC because there’s no real “identity” component at read-time.
pcdevils 9 hours ago [-]
You can use Mozilla SOPS instead with IAM roles and KMS instead of gpg.
They also shifted to AGE over gpg.
lkjdsklf 1 hours ago [-]
It’s the same problem. You don’t have an audit trail. That’s needed in a lot of situations for compliance reasons
chrystalkey 7 hours ago [-]
What a soup of acronyms
embedding-shape 11 hours ago [-]
Git submodules + SSH keys is another (somewhat "homebrew") solution to this.
arka2147483647 10 hours ago [-]
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.
bc1000003 5 hours ago [-]
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 5 hours ago [-]
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.
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 9 hours ago [-]
> 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.
a1o 5 hours ago [-]
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
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 8 hours ago [-]
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 5 hours ago [-]
LFS is not installed by default alongside git, it's a separate package in most systems
jayd16 10 hours ago [-]
P4 is more "industry standard" than "state of the art"... But it does handle large files and partial checkouts without feeling bolted on.
manoDev 10 hours ago [-]
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 9 hours ago [-]
One of those ideas that sounds clever in theory but in reality doesn’t work very well
bigbuppo 9 hours ago [-]
Also... it's kind of weird taking a decentralized system and recentralizing it.
9 hours ago [-]
apatheticonion 4 hours ago [-]
Another thing git isn't good at is massive codebases with long histories. IMO git should have a configuration option to pull commits lazily without the need for `--depth` and the `git fetch` dance that goes along with it.
woctordho 2 hours ago [-]
There's `--filter=blob:none` and it allows to automatically fetch blobs when needed.
apatheticonion 2 hours ago [-]
I wish it was as simple as `git clone <url> --lazy`
I had previously worked on a big tech monorepo that has gigabytes of history. It would take forever to clone or do operations on. I had a cheat sheet of git commands that would do things lazily but I forget them (which is the issue).
debarshri 11 hours ago [-]
I am building a small asset heavy game. Ran into a similar problem. Built a storage cost efficient tool for exactly this [1].
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.
kvirani 10 hours ago [-]
There's also a new player called diversion (diversion.dev) which I think may be a YC startup? Anyway it takes a different approach of being more like Google drive but bringing in VCS behavior making it more indie and designer friendly.
danudey 10 hours ago [-]
At my previous game-dev-company job we ended up splitting things up into:
1. Code - Git
2. WIP art, shared assets (logos, marketing materials, etc) - Google Drive (because things are often changing, getting passed around, etc)
3. Finished assets (PSD files you're done with, or you think you're done with) - SVN (because we wanted a log of who contributed to what, wanted artists to be able to pick up where someone else left off; having a log of who made changes to a given PSD)
4. Assets rendered out to PNG to include in the app bundle/publish to the static file servers - Git (because those files never changed after being published so the git history wasn't polluted with unneeded files)
I've also used LFS, which is... a fine workaround, but still not great. Users who don't have it configured can still commit binary blobs; users who don't have it configured will clone files incorrectly; if the LFS server is slow, unavailable, unreliable, then the system starts to behave oddly; you need a Git server that supports it.
It was a huge hassle to manage; having a system like this would have been a godsend at that company, and if I still worked there I would be spending all day importing our codebase and assets into it to see how well it works.
maccard 5 hours ago [-]
Yeah that seems like an awful solution. This is exactly why we use perforce and just shove _everything_ in it.
cpeterso 2 hours ago [-]
Why was SVN preferable over git for finished assets?
red-iron-pine 9 hours ago [-]
what happens if WIP stuff has rapid shifts or changes? art direction changes on the product level, etc? or even something as simple as an asset designer quits or get sick for a while
SVN makes sense cuz it's done and dusted, but I could see the Drive gettin real messy real fast if things change a lot
Decabytes 11 hours ago [-]
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
827a 11 hours ago [-]
This presumption has destroyed far, far more companies and projects than the opposite assumption (that something built for small will scale to big, then doesn't).
qmr 10 hours ago [-]
Can you name five?
827a 5 hours ago [-]
Kubernetes and the one I'm working at right now.
throw2ih020 1 hours ago [-]
It is truly a tragedy that the story for scaling Kubernetes beyond 3k-5k VMs is "run multiple clusters'. It's 10% overhead for tiny scale, doesn't scale well to large scale- it works well in this happy midrange of 7-3000 VMs.
(If anyone is about to ask why you would need that many VMs - many companies who do extremely large scale infrastructure! The kind of software where when it breaks it can create a crisis for utilities, governments, healthcare systems, militaries, etc.)
calculus01 5 hours ago [-]
[flagged]
LinearIO 10 hours ago [-]
P4 is also really well integrated into IDEs and UE Editor so that I don't need to think about it as much as I need, compared to Git. Locking assets, releasing them, merging into streams etc., is overall pretty streamlined. When it works, it's great, but when it doesn't work though, it's pretty hard to diagnose issues.
PaulDavisThe1st 6 hours ago [-]
One of the many points of git's design is that most of the steps you need to do in P4 are not necessary at all. You do not "lock assets", you do not "release them", there is no "merging into streams" equivalent.
The entire workflow with git avoids huge amounts of the cognitive load of using P4, which in turn means that integration with IDEs becomes much less important.
I worked with P4 around the time I first started learn git (coming to both from SVN). P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git". So glad to be far, far from that particular tool now.
FanaHOVA 6 hours ago [-]
Solving merge conflicts on text-based files is infinitely easier than binary-based. It's not a useful comparison.
PaulDavisThe1st 4 hours ago [-]
What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?
forrestthewoods 4 hours ago [-]
> You do not "lock assets",
Uhhhhhh. Locking binary assets is ABSOLUTELY NECESSARY in Git. Except Git can't actually do that. So what locking binary assets Git looks like in practice is an unenforced message in Slack saying "hey I'm changing this file please no one else touch it".
Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.
> there is no "merging into streams" equivalent.
Weird take. Streams is Perforce's mediocre take on Git branches. P4 stream merge is close enough to Git branch merge that I would say they're in the same family.
> P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git".
And yet Git has almost zero mind share in gamedev because it doesn't solve the problem.
P4 is somewhat mediocre. And it's made zero improvement in ~8 years since getting bought up by PE.
But I can also teach a game designer or artist who has never heard of source control how to correctly and safely use P4 in about 15 minutes. Meanwhile you can tell Git is badly designed because there are 10,000+ tutorials explaining how easy it is! Spoiler: things that are actually easy do not need 10,000 tutorials telling you that it is easy.
PaulDavisThe1st 3 hours ago [-]
> Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.
OK, I think this is well-established by up-thread comments, and I don't disagree with it at all (though note that its not just binary assets, it's anything that isn't line oriented, which includes for example XML).
I didn't realize that LinearIO's comment was really that specific; it appeared to be describing general properties of P4 unrelated to the binary issue.
The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say.
I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.
maccard 3 hours ago [-]
> The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say.
It's "hard to say" if you want to ignore the fact that it requires 10k tutorials. Meanwhile, there are 500+ person companies with non technical users using P4 with literally 0 onboarding other than "by the way, undo is broken don't use it".
> I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.
Using P4 is: Download P4V, install plugin for $EDITOR, and double click on a changelist to submit.
woctordho 3 hours ago [-]
It's 2026. Historically the way for large binaries in git was git LFS. Now the way for large binaries in git is just git.
A significant part of my job, unfortunately, is helping people fix their workspaces when Perforce (p4) goes bad, or creating guardrails and wrappers to stop Perforce doing bad things.
In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.
For example:
- p4 tracks file metadata of client workspaces on the server (sync'ed locally, opened for edit, file revision, etc) and uses this as the basis to avoid doing unneeded work. If this becomes desync'ed, a reconcile or force sync must be used. A reconcile can take hours, potentially days; it tries do detect file moves by default, so likely at least O(c^n) for some c>1. I have never personally seen a default reconcile operation _complete_ over any modestly large game code base, and in practice, people accumulate a litany of workarounds and scripts to fix this for themselves.
- Scripting p4 is a nightmare. Documentation is poor, schemas do not exist, and all the language-specific libraries are just thin wrappers over its C++ API.
- By default, p4 "helps" you with text files by "correcting" line endings on sync or even converting between encodings. This works until you have a mixed-OS environment, and discover a part of the pipechain that _must_ have a certain style. There are various levers to pull to make this better, but I've yet to find something fool proof.
- By default, p4 keeps flies read-only, only unlocking them when explicitly marked as being edited. This means, to avoid having to do this manually, every tool you use needs to be p4-aware. Or, you can turn this off, and choose to contend reconcile instead. (See above)
- Branching a modest game project, with, say, Unreal source code, can take hours. And this is the quick version where you ask the server to simply create new metadata, with no file transfer to a client.
- p4 is licensed by the user-account. Every user entity in p4 not intended exclusively for performing backups and maintenance operations counts toward this, including users required to integrate with other services. Plus, often times, these integration users must have admin access to be useful. The security posture is horrific.
danbolt 2 hours ago [-]
Reconciling is my least favourite part. It always feels like everyone’s checkout is a unique blend of local files and permissions you have to fix up now and then. It can be hard to keep track of how much one’s deviated.
I can understand how git isn’t always appropriate for less technical workflows and large file sizes, but p4 pain is its own character.
bryanlarsen 9 hours ago [-]
> p4 predates most of the VCSes we consider "modern"
p4 also significantly predates VCSes we consider obsolete. p4 is almost a decade older than SVN.
antod 6 hours ago [-]
20yrs ago, for me migrating off p4 onto svn was such a relief and feeling really "freeing" in a way I haven't felt often.
htr0waway2 8 hours ago [-]
> Scripting p4 is a nightmare
This is why I wish more command line tools were split into a library that does most of the work and a cli module for purely user interaction. Parsing stdout seems so unnecessary and could be avoided if a program could simply import a library.
arka2147483647 10 hours ago [-]
I’ll add some more
- The P4 cpp api was apparently designed before any modern Cpp std lib was available. And is at best archaic, and stringly to use.
- P4 encoding support is pain in the ass to configure. And ensist on adding or removing bom to files.
lkjdsklf 56 minutes ago [-]
Modern cpp is a bit of an oxymoron
seniorThrowaway 7 hours ago [-]
I've had the misfortune of scripting an UE build with perfoce as the VCS, it truly is abysmal.
reactordev 9 hours ago [-]
Has nothing to do with Perforce being the Oracle of VCS because it’s baked into the big 3? Riiiight.
WorldMaker 8 hours ago [-]
Perforce is more the IBM of VCS. Older than it has any right to be. Has quiet "dark matter" support contracts with a lot of companies you wouldn't think need Perforce, but they've been using it for long enough they aren't going to change. Some of those support contracts included complicated forks and homegrown solutions that are so sunk cost as to be nearly black holes (and sometimes so different from baseline Perforce as to be evolutionarily different species).
computerdork 8 hours ago [-]
Well another factor could be that Perforce is a lot easier to use than Git - Actually, would like to think am good with git, but sometimes just wonder how it became so big considering the simple or important things (like check-ins and merges) are so complicated.
reactordev 7 hours ago [-]
check-in isn’t a concept in git because there is no server in git. It’s just a log. The beauty of the merkle tree. It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source.
Delta patches become effortless
maccard 3 hours ago [-]
> It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source.
If everyone uses it wrong, it was designed wrong. See Q-tips.
PaulDavisThe1st 6 hours ago [-]
git is so agnostic about all this stuff that you can even merge completely disparate, unrelated repositories (for example, my own primary "job" repository, and the linux kernel) into the same on-disk structure. Of course, doing so is useless because none of the commits from one repo has any relevance to the other. But because the commits are identified by true GUIDs, there are no collisions, and both sets of commits can happily exist in a single repo.
It's of almost zero utility, but it does (for me) heighten the beauty and elegance of the concepts behind git (and even, the actual implementation).
mietek 4 hours ago [-]
I found the ability to merge unrelated repositories very useful when collecting various bits of work I did separately and combining it into a single library.
jhatemyjob 9 hours ago [-]
It's not even baked into Google anymore.
Arainach 7 hours ago [-]
Technically correct, but Piper is API-compatible with Perforce, so while there's presumably no license fee it's still strongly there in spirit.
It's hardly the same thing at this point. For instance you could say Nginx is API-compatible with Apache, and yes that is correct (Maybe? Let's not split hairs here). But to go as far as saying Apache is state of the art and link to Apache's homepage (like throw2ih020 did) is just like.... no.
I think you think I'm trying to correct/one-up reactordev. I'm not. I agree with him. He's pointing out throw2ih020 is being ridiculous, and I'm pointing out that it's even more ridiculous because it's less than 3.
reactordev 6 hours ago [-]
Is Google a big 3 media/entertainment studio?
While I agree with you, not at Google anymore, I do not consider them the top 3 engine providers that I am referring to in my post. No no, Unreal/Unity/Red/EA/SC it’s all perforce.
jhatemyjob 5 hours ago [-]
Ahhhh. Okay. I didn't realize you meant game studios. Wasn't familiar with that "big 3" term until now. Thanks for clearing that up.
reactordev 5 hours ago [-]
Tech in general, you’re spot on though.
throwaway81523 10 hours ago [-]
> 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
Git-annex ?
MayeulC 5 hours ago [-]
Ah, that's interesting, the requirements are similar in the CAD industry. Dassault Design Sync is used a fair bit for semiconductor design databases, for instance. An open alternative would be welcome!
Edit: I do feel a bit uneasy about epic games, though.
ultrahax 9 hours ago [-]
Can confirm, we have a team dedicated to the care and feeding of p4.
throw0101c 8 hours ago [-]
> 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.
How well does Mercurial work in this situation (or even Subversion, given that Perforce is non-distributed like SVN)?
minraws 6 hours ago [-]
Mercurial is a bit better, but not by much it had slightly better large file support historically but I wouldn't recommend it.
Calgaryp 6 hours ago [-]
I totally agree.
I worked with Unity for a small indie game and it was sooo hard to use git with my team and merge things like game scenes etc.
ur-whale 11 hours ago [-]
Git is certainly not great with binary assets, but calling perforce SOTA ... ouch.
If perforce is the best there is out there for large binary asset management, then there is a blue ocean worth of potential improvement for git.
Perforce is a piece of crap, a relic of the 20th century that must die in a fiery inferno.
danudey 10 hours ago [-]
It can be SOTA and still be garbage if there's nothing better (and there's nothing better, sadly). This is extremely exciting for anyone who's had to manage revision control for game devs.
maccard 10 hours ago [-]
I’ve spent more than a decade working in games and unfortunately perforce is the best out there for a variety of reasons. None of them are good.
asveikau 10 hours ago [-]
15 years ago, both Google and Microsoft were on perforce. (The latter through a fork with a different name.)
kps 10 hours ago [-]
Google still uses Piper, which started as a Perforce clone, though many people use it through a frontend like `fig` (try pronouncing ‘Piper HG’) or `jj`.
DonHopkins 7 hours ago [-]
Git LFS causes nothing but pain, suffering, and regret.
slowmovintarget 8 hours ago [-]
Seems to me that this would be great in general software development for just checking in your dependencies as binaries. No more build-time supply chain attacks with vetted binaries.
IshKebab 8 hours ago [-]
> this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development.
Well, it is intended to compete with Git for version control. It's just that Git happens to be so bad at some aspects of version control that it isn't used much in those cases.
There's no good reason that Git couldn't be good at versioning binary files, or splitting up large projects. I mean people have tried - there's LFS and submodules. It's just that those both suck balls.
I was kind of hoping Jujitsu or Pijul would take a stab at these major Git deficiencies but unfortunately it seems like they are content to do them as badly as Git does.
WorldMaker 8 hours ago [-]
It feels like a Pareto Principle problem. 80% of source control is text files that can be three-way merged as text files, but a lot of hard problems are in that 20% that isn't.
Git does very well at the 80% and with tools like custom merge tools and git lfs/annex and git sparse "cone" checkouts can get pretty close to hitting the 90 or 95% case.
But yeah, so many of those extra tools in that 80 to 90% area are awful to work with because they aren't the default, aren't out the box, are hard to configure and get right. Partly because it always seems like there will be a gap in that 95%-100% window and partly because the use cases that need that 80% to 90% often are only "just 10% of use cases".
(Which is also to say that to survive Jujitsu and Pijul and others seem to have to work to make sure they handle the 80% base case extremely well just to compete with git, they haven't necessarily time to think about the 90% or 100% problem.)
(ETA: And also relates to why game development seems to feel the 20% cases more, because by volume of data game development is certainly closer to a flip of the 80/20 sides with 80% or more large binaries by volume.)
1718627440 4 hours ago [-]
That it is difficult to merge e.g. media files has nothing to do with Git. It's just that it is one of the core assumptions in Git, that it is fine to diverge locally and cheaply, because you can just merge. I think this can't really be solved without a centralized server and that is just something, that Git doesn't want to be.
WorldMaker 3 hours ago [-]
Yeah, decentralization is an important principle to git and tools to manage concurrency such as "file locking" become a lot harder to do in an a decentralized way than a centralized one. (Pijul has the same problems because decentralization is also an important principle to it.) It is something of a problem space that transcends beyond git. But I also think this is how we've arrived to this moment where the best source control tools have decentralization as an important principle. That 80% case with easy mergeable text files is a lot nicer to work with in a decentralized world because it is "offline-first" and quite capable. It often seems, across a lot of different styles of software development, worth the trade-offs that things like media files are harder to work with. (Again, realizing the obvious problems with game development where that often flips and the majority of work is often in the media file assets as much or more than the text files.)
IshKebab 5 hours ago [-]
I would say that at least the submodule problem is more like the last 45%. Every single company I've worked in has ended up using submodules and it always ends up causing huge amounts of pain because they suck.
The only alternative Git offers, which is slightly better IMO, is monorepos. But they're only slightly better - they also have really significant downsides.
I'm 100% sure there's a much nicer solution to the kinds of problems people use submodules for that isn't submodules, but as far as I can tell zero people are trying to find it, despite it being such a universal problem.
WorldMaker 3 hours ago [-]
From my viewpoint, a lot of the submodule problems are effectively same as the monorepo problems, including how you end up with both problems. There certainly are factorings of projects into "microservices" and moving the dependency management problems out of source control to package managers of different types. Microservices and package management sure do have their own problems and trade-offs and there isn't a "universal solution", just what side of the trade-offs you prefer to be on.
yemi43 5 hours ago [-]
[flagged]
TheBigSalad 11 hours ago [-]
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?
bigstrat2003 10 hours ago [-]
I was. I thought, and still think, that svn was much more pleasant to use than git. Alas, I am in the minority.
danudey 10 hours ago [-]
SVN was more straightforward to use, but that straightforwardness lost a lot in terms of fidelity.
The fact that it was easy to clone a subdirectory was nice; the fact that branches were just subdirectories also was not nice. The fact that tags were mutable since they were also just subdirectories... the fact that every operation you ever did required going to the server (commit, log, checkout, everything) made it a pain if you were on a slow link.
I can't count the number of times I was inspecting SVN history and had to just 'svn log > /tmp/svn.log' so I would have the whole log locally rather than having to hit the server each time I wanted to refine a grep.
WorldMaker 8 hours ago [-]
Also, for a lot of SVN history running it required such a specific Apache webserver setup that it was at times complex to configure correctly and made it comparatively expensive to find SVN repository hosts. SVN seemed cheap mostly only if you had cheap labor for infrastructure. Very few hosts got to "forge scale" like SourceForge did with CVS or GitHub would eventually/"quickly" do with git.
Zardoz84 9 hours ago [-]
git-svn did wonders when we had the code base on subversion
danudey 7 hours ago [-]
git-svn is good for interacting with an SVN repository using git, but if you want to do a full-on migration there's a lot more to do.
I ended up using KDE's SVN migration tool, which was extremely featureful and versatile, as it was designed for the case of moving a massive, complex SVN repository into multiple separate Git repositories, filtering files/directories, importing tags/branches/etc. Saved me a ton of time.
My favourite part was at the end when we migrated the biggest, most important repo, a lot of the original SVN commits were imported from CVS, meaning we had a direct CVS-to-SVN-to-Git migration keeping all of the original metadata from the CVS commits (such as it was). The data purist in me rejoiced.
SVN was actually quite decent for game development, definitely more robust and (non-technical-) user-friendly than git+lfs.
(and SVN isn't really compatible with the work-from-home era unfortunately, you really needed a big server on a gigabit LAN)
TheBigSalad 8 hours ago [-]
Yes. Some software is just really bad.
11 hours ago [-]
jaapz 11 hours ago [-]
turns out version control is hard
irishcoffee 11 hours ago [-]
We did, mercurial just didn't win.
redsocksfan45 10 hours ago [-]
[dead]
zer00eyz 11 hours ago [-]
Git is fit for purpose. That purpose is to host a monorepo, with out a lot of 3rd party dependancies, distributed, patch based.
Thats not how everyone else works.
We're all using package managers to help with massive amounts of 3rd party dependancies (why are you version pinning in any place other than your repo, why arent you pulling updates through your repo and reviewing them)
We're reliant on tools like artifactory to make sure those depedancys dont disappear or are not corrupted.
We use yet other tools to manage our binary files (this tool would fix that).
Github, gittea, gitlab, bitbucket... have all added piles of tooling around git, that are grafted on around its short comings.
> It's crazy to me that nobody has made anything better yet.
> Although I could start that myself and yet have not.
Because unless your a Google or a Linus, no one is going to look twice at your tool for something that is this important. Im not even sure that epic games has the good will, or trust to launch this.
I am going to give them the benefit of the doubt and take a long hard look at it, but my optimism is tempered. But unless it offers a LOT more than git, the extra overhead (lacking IDE support, deployment changes and all the other tooling in GIT's orbit) it isnt going to be a worth while change.
LtdJorge 10 hours ago [-]
This tool is not for pure source code. It's for videogames. Videogame-specific VCS have been lacking much more than Git has, since the start. As others have said, the biggest problem is undiffable binary files.
TheBigSalad 7 hours ago [-]
Because our entire industry has fallen into the rut of "more tools"... rather than fixing the real issues that hold us back.
This is why I'm not motivated to build something better. I don't think anyone would care.
chadgpt3 12 hours ago [-]
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.
Aurornis 12 hours ago [-]
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.
rootlocus 12 hours ago [-]
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."
Aurornis 11 hours ago [-]
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.
cjbgkagh 11 hours ago [-]
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.
somenameforme 10 hours ago [-]
Is it not also possible that there are an overwhelming number of problems with the big AAA type studios in games right now? I feel right now we're in sort of tale of two cities, because AAA games have turned into barely functioning uninspired parasitically monetized crap, while smaller scale development is in an absolute golden age. And it's likely that LLMs will only add fuel onto this turd burning fire.
A_D_E_P_T 8 hours ago [-]
In fairness, AAA games are practically over. They have grown too bloated, take too long to develop, and, with the culture wars raging in the background, almost every AAA game steps on at least one landmine and loses a large fraction of its audience before it is even released. Sad, really.
Aurornis 8 hours ago [-]
There are real problems, but Jonathan Blow doesn't limit his criticism to those problems. He just indiscriminately criticizes everything. He's turned into the type of critic that is a broken clock that happens to right twice a day.
His criticism isn't limited to AAA game studies. He's a vaccine skeptic and is pretty heavy into far-right influencer garbage. All very surprising if you only know him from his games.
> It doesn't help that all males currently under the age of 40 were raised to be supercucks
I started following him for his gaming work and talks. His influencer content is something else.
wredcoll 8 hours ago [-]
Anyone still following him after that needs to fundamentally reevaluate some life decisions.
cjbgkagh 10 hours ago [-]
That is what makes it cult like and not a full on cult, there is a lot of truth to what he says. The problems is when the conclusions are extrapolated out to absurdity - it’s hard for me to listen to it. I didn’t take sufficient notes to give a proper recount here and it’s a bit too much work for me to go through it again.
Fraterkes 10 hours ago [-]
I’ll chip in here and say theres ime a world of difference between the amount of condescension and acerbic noise produced by Blow versus Casey. Casey comes of as grumpy but fundamentally pretty respectful in the stuff I’ve seen him in.
bigstrat2003 10 hours ago [-]
I have only seen Casey's writing in the whole "why is the terminal so slow" debacle, but he was a massive jerk in that. He was right! But still a jerk.
Jare 7 hours ago [-]
I often feel that while Casey can end up saying you're an idiot, he does not believe you are, only the things you do are. And given the chance, he will happily and warmly engage with "why smart people do idiotic things".
Whereas JB actively thinks you're an idiot, and the things you do are idiotic because of your stupidity, period.
klodolph 11 hours ago [-]
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.
troupo 11 hours ago [-]
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.
rootlocus 11 hours ago [-]
To be fair, game developers have been rendering text on the GPU for over two decades. I've done it in college a decade ago with bmfont [1] (nowadays the engine does rasterization during import). Whoever thought was making a case with "outputting text to a terminal emulator is a PhD level problem" was really out of their depth and was making a case for unnecessary inefficiencies. Kudos to Casey for proving a point.
I remember when that terminal situation first happened, and my main takeaway wasn't "wow, this Casey guy is a genius" but rather reinforcement of my pre-existing belief that Microsoft is full of incompetent and lazy people. Anyone who has ever dabbled in engine or low-level game dev has implemented basic GPU text rendering at some point.
Matl 11 hours ago [-]
Yeah, like when Blow claimed he could replace PowerPoint in a weekend and ended up implementing a presentation software that had about 2% of what PowerPoint offers.
Now there's an argument to be made that many don't need the remaining ones but to claim that you 'replaced PowerPoint' for anyone but yourself is ridiculous.
They're good at demos, I give them that.
duttish 11 hours ago [-]
There's a classic saying along those lines, "everyone is only using 5% of Word. The tricky part is that everyone is using a different 5%"
munificent 7 hours ago [-]
C++ is the same way and is why while everyone hates 95% of it, no one can agree on a strictly superior language.
rjrjrjrj 8 hours ago [-]
Originated (or maybe just popularized) by Joel Spolsky, I think?
LtdJorge 10 hours ago [-]
Casey was right, though. The windows terminal was (is, it's still there even if you use the new Terminal) atrocious. The performance is so bad, due to going through all the layers it does, which Casey exposed. And it's not even packed with features, pressing up on a new console doesn't bring you a command from history, which Linux terminals and 3rd party Windows ones have been doing for decades, even Powershell does that. The support for colors was also bad, the very limited options for font configuration, and it renders fonts as if it was Win2k... Thankfully, the Windows Terminal solves most of those, and includes tabs and other useful features. Too late for me as I already jumped ship to Linux.
ahtihn 9 hours ago [-]
> pressing up on a new console doesn't bring you a command from history, which Linux terminals and 3rd party Windows ones have been doing for decades, even Powershell does that.
I'm wondering if you're confusing Windows terminal with cmd.exe?
Windows terminal is not the shell. It's a terminal emulator. You run a shell inside of the terminal, for example you can run... Powershell.
Command history is a feature of the shell.
moogly 8 hours ago [-]
Imagine if he had approached it like, e.g. Bruce Dawson though, instead of coming off like an edgelord off his meds.
chadgpt3 12 hours ago [-]
Isn't that kind of the point though? Doing more with less?
Wowfunhappy 11 hours ago [-]
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.)
9 hours ago [-]
flohofwoe 11 hours ago [-]
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.
LugosFergus 12 hours ago [-]
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).
superdisk 11 hours ago [-]
He uses SVN and specifically has stated that Git isn't suitable for the work he does due to big binaries in source control.
pton_xd 12 hours ago [-]
How do you merge changes to a texture, mesh, audio file, etc?
rootlocus 12 hours ago [-]
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.
regnerba 12 hours ago [-]
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.
regnerba 12 hours ago [-]
Permissions is another thing. Git permissions are done one a per repo basis.
Also, Lore seems to support checking out only the assets you actually need (on-demand hydration and sparse checkouts), meaning that a level designer can check out just the level that they're working on without having to manually configure a git sparse-checkout (and then not being able to see any of the non-checked-out files).
If this supports dynamic hydration of files, either as they're accessed (like Dropbox with offline files) or by somehow knowing which files need which other files (building a dependency graph) then it could be a massive win both for speed and efficiency of downloads but also for conserving disk space on developer machines.
And since it has API bindings, it's possible that's something that could be built into IDE plugins, so that your editor (Godot, Unity, etc) can know which assets need which other assets and automatically trigger hydration, including when you e.g. try to use a new model/texture/etc in a scene that hasn't used it yet.
throw2ih020 12 hours ago [-]
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.
flohofwoe 11 hours ago [-]
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 though that for small game projects, git is mostly 'good enough', even without lfs).
zipy124 11 hours ago [-]
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.
danudey 9 hours ago [-]
> 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.
At Fortinet we migrated our SVN repositories to git and ran into a ton of issues; developers over the past ten years had done tons of little mistakes that added up, like accidentally checking an entire Windows virtual machine into the repo. In SVN they deleted it and no one ended up caring, but in Git of course it became part of the repo history.
I did a huge amount of work for the migration, 99% of which was analyzing each repo to find out what files/file extensions were overly large, and then either:
1. Filtering them out of the git history completely during import
2. Converting them to LFS objects after the import
The LFS process was certainly better than the other alternatives, which were 'check everything into the git history' or 'remove all the un-diffable binary files and hope that they weren't needed for anything', but it was still not ideal.
Every developer (out of thousands, across multiple countries, timezones, and native languages) had to set their system up properly; if you missed a command, or if you reinstalled your OS and forgot to set up one of the aliases or hooks, then you would end up checking binary blobs into git rather than LFS, or checking out LFS idents rather than the actual files they needed.
We also had the issue of developers fetching code over SSH but LFS files over HTTPS, which would be fine except that we wanted to prevent access to HTTPS from most subnets, so while the developers could use SSH to clone or pull using their 2FA token their client would then make an HTTP request that wouldn't work unless they were on the version control VPN, which.... blah blah blah.
So yeah, it worked better than the alternative, but it did not work _well_ a lot of the time.
Tiktaalik 11 hours ago [-]
There's also the tooling. Game teams have artists and designers where baroque command line incantations are headwinds to their workflow pace.
For the longest time Git tools were really poor. In recent years there's a few ok ones, like Git Fork, though I wouldn't know if those tools scale to the level of a AAA team size repo and not fall over.
lentil_soup 12 hours ago [-]
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
danudey 9 hours ago [-]
I mean, Git LFS 'supports branches' in that the LFS content identifiers are checked into git as files and Git operated normally; LFS is just a way to replace those content identifiers with the actual content, and then vice-versa when you commit.
I think branching is the one thing that didn't get more complicated with LFS.
niek_pas 12 hours ago [-]
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
e40 12 hours ago [-]
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 9 hours ago [-]
> 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 9 hours ago [-]
That makes me sad. This termainology is really one of the major flaws of git, along with the checkout/reset thing
Are those three really all the same things? That seems crazy to have all three not consolidated.
1718627440 4 hours ago [-]
Cache is like the old name, index is the new name, because the implementation didn't really make sense to use as a term for the users. Staging area was invented by third-parties as a term for training. Now Git uses --cached to mean only work on the context cached in the index and --index to mean also look at the --index. --stages exists as an alias for --cached for the people who want it, but it has no additional meaning and is not advertised in the documentation.
The actual documentation is actually sensible, the issue is just that most people just learn from third parties, who are lax with terms.
> At the end user level, "cache" is only used as an adjective these days; "cached", meaning "contents cached in the index, not the contents in the work tree". We could have called it "indexed", but "cached contents" was an already established phrase from very early days to mean that exact concept, and we did not need another word that meant the same thing.
> There are some commands that take --index and --cached options, and even some that can take both (but not at the same time). Many people find this confusing, but there is a pair of simple rules:
"--cached" always means "work only on contents cached in the index, ignoring the work tree";
"--index" makes a command that usually works on files in the work tree also pay attention to the index.
> Here are a handful of examples.
"git apply" usually patches the files in the work tree without touching the index.
"git apply --cached" only updates the contents in the index without modifying the file in the work tree.
"git apply --index" patches both the contents in the work tree and in the index.
"git diff HEAD" shows a patch to update the contents in the HEAD commit to contents in the work tree.
"git diff --cached HEAD" shows a patch to update the contents in the HEAD commit to contents that is cached in the index. "git diff --cached" is a short-hand for "git diff --cached HEAD" only because the HEAD commit is what you most often would want to compare the cached contents with.
There is no "git diff --index HEAD" (yet); it would imply showing a three-way diff between HEAD, the index and the work tree.
"git grep" finds matches in the work tree.
"git grep --cached" finds matches in the contents in the index.
"git rm" removes both the file in the work tree and the corresponding path in the index.
"git rm --cached" removes the path from the index, leaving the file in the work tree untracked.
skrebbel 7 hours ago [-]
Yes.
js2 9 hours ago [-]
I understand there's friction in contributing to git, but it's absolutely possible to improve the docs:
Do you have a link to your proposal on the git mailing list?
maccard 11 hours ago [-]
> 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 11 hours ago [-]
Luckily it’s an open source project so you could go in and clean up the ux.
andrewflnr 9 hours ago [-]
Great, then your choices are (a) try and probably fail to get your changes upstreamed and/or (b) maintain your own fork of git forever.
This is very much a "if you don't like X about your country, just move to a different one" kind of "solution". The costs are extreme to the point that pretending it's viable is insulting. Really it's just a way to silence legitimate complaints.
MobiusHorizons 2 hours ago [-]
to be fair, if you just want to improve the UX for yourself you can totally have a fork, make your changes, and use it on your own machines when talking to github or whatever other git repository. Now getting someone else to accept your changes might be harder, but that's what happens when you try to change a tool so many people use, especially one with a lot of history. Maintaining a fork is literally one of the things git was designed to make feasible after all.
8 hours ago [-]
LtdJorge 10 hours ago [-]
Probably unacceptable as many would have built tooling around the specific default behaviors.
throw_await 9 hours ago [-]
If tooling is relying on the output format of porcelain commands, it's wrong. The output of various subcommands have already changed more than once.
tredre3 7 hours ago [-]
Relying on porcelain commands' output is the official way of interacting with git, they famously always refused to break it into a library. Nobody is going to use the low level git commands because: 1. Their output isn't any more reliable than the porcelain, and 2. How the porcelain uses them is also subject to change, so your UI might end up doing something different from the git high level command which is undesirable.
At least they gave us the `--porcelain` flag, meant exactly for this use case, to make the output format of porcelain commands never change. Dumb flag name, though.
Jaxan 10 hours ago [-]
You can have your own version. You don’t have to push all improvements upstream.
swiftcoder 9 hours ago [-]
It's not really feasible to maintain private forks of every piece of software you use (especially something like git that needs regular security patches)
1718627440 4 hours ago [-]
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 11 hours ago [-]
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):
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.
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.
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 6 hours ago [-]
> 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 4 hours ago [-]
> 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.
sundarurfriend 4 hours ago [-]
And yet, even for programmers, that output is full of info that is useless 99.9% of the time. That is just bad design. It is basically a debug log that is shown by default all the time, instead of written to a log somewhere for the <0.1% time it's useful.
And I point out the attitude because I've seen it for decades and seen the harm this kind of "it's just harmless extra info" type thinking has brought. I don't know what tone you're reading into it, but I'm quite literally and explicitly criticizing the attitude, not you personally.
squeaky-clean 1 hours ago [-]
> FFS, git is a tool for programmers.
We already said it has a garbage UI, you don't need to repeat it
But jokes aside, usually the reason something is considered a "tool for programmers" and not just a tool is because the UI sucks.
dansmith1919 7 hours ago [-]
The point is that if it's useless information for 99.9% of users, what's it doing in the UI?
1718627440 4 hours ago [-]
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 6 hours ago [-]
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...
gbalduzzi 5 hours ago [-]
How often do you really need to look at that info while doing normal work?
Because to me and to the very vast majority of git users it is totally irrelevant.
It is nice that the info is available, but the more sane default would be to hide under a verbose flag not the other way around.
Imagine typing cd folder/ and have the whole filesystem subtree be displayed in the terminal. You are free to ignore it, but it is useless and inconvenient nonetheless
js2 4 hours ago [-]
Are you not a programmer? Do you not ever find yourself having to debug an issue? When you have to, are you not glad when there's sufficient information in the log files to do so, even though 99.9% of the time you never look at the logs?
> Imagine typing cd folder
It's not comparable. `cd` is a local command (technically a shell built-in) that completes instantly (unless you cd to a hung NFS mount...). So it honors the Unix philosophy of emitting nothing on success.
But cloning is a network operation. And it's normal for networking tools to output progress by default. See `wget` and `curl`.
The problem with hiding progress under `--verbose` is that by the time you need the information (why is this taking so long?), it's too late to add `--verbose`. You'd have to cancel the command and run it again losing progress.
If you don't want it, then use `--quiet` and move on with your day.
(Sure you could make it smarter by deferring outputting anything until it realizes the operation is taking some time. Patches welcomed.)
genocidicbunny 9 hours ago [-]
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 8 hours ago [-]
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.
genocidicbunny 8 hours ago [-]
I apologize if I came off harsh and combative. Gamedev is a passion for me and I spent many years in that field, including working on proprietary version control systems because existing ones like SVN, Git, Perforce...etc did not fit the needs of the team.
One of the things I very frequently heard from the non-programmer disciplines was how obtuse and indecipherable the existing version control systems were. That is where I'm coming from.
Your knowledge is still appreciated, by me as well, because while I am well familiar with the way git works, I have worked with many people who were not, and did not have the time or budget in their minds for understanding it because they had many other concerns. That is what I mean when I said that I worked with some brilliant people -- I could not do even a modicum of what some of them were capable, and likewise they probably weren't capable of the same modicum of what I was doing.
I don't know what specifically the GP post was trying to insinuate, if anything at all, but it resonated with me as someone who had experienced the same thing many times over in my career. And I probably judged your comment a little harshly on first read, which is mea culpa. You provided good information for those newer to git and seeking to understand how it actually works besides the cheat sheet guides you so often find.
> 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.
Precisely, and I think Lore is an interesting proposition for exactly that reason.
1718627440 4 hours ago [-]
It's a progress indicator. Everyone has had the concept of percent in school even if they are an artist.
genocidicbunny 1 hours ago [-]
No, it's mostly nonsense to them.
You know what's a progress indicator? An actual progress indicator. Not some text telling you such and such process is 1234/5678 steps done...followed by yet another line of text telling you that the process is now at step 3 of 20. It could just be a % indicator with a spinning cursor, unless the -v/-verbose flag is present.
Of course artists can learn to understand what all this means; But that is not their job, they have other things to deal with besides the esoteric and overly verbose CLIs we programmers often make.
jen20 8 hours ago [-]
> 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).
genocidicbunny 8 hours ago [-]
While I agree that git is a tool for the development of an operating system kernel, it's become clear that this is not the general perception of it. I don't mean those of us who have followed it throughout it's evolution, but those that are not 'in the know'. I have heard probably too many programmers pushing it as the end-all-be-all solution for version control even in environments not appropriate for it.
I will disagree that the output is too complex; it is. And yes, the large binaries issue is also a huge challenge to it's use. There's only so much time in the day, and when you work in gamedev there are often severe pressures to perform, and spending extra time to get into the weeds of a version control system is often not possible without sacrifice.
jen20 1 hours ago [-]
> but those that are not 'in the know'.
Those are not the target market, and that is OK.
> spending extra time to get into the weeds of a version control system is often not possible without sacrifice.
Which is why most Gamedev places use perforce and not git. Or, perhaps now, Lore.
mariusor 7 hours ago [-]
Your straw man artist should use any of the nice frontends that work on top of git and hide its verbosity.
genocidicbunny 7 hours ago [-]
> artist should use any of the nice frontends that work on top of git and hide its verbosity.
Right up until something goes fucky. You know how many times I got messaged by someone dealing with vcs going wrong for them at a late hour in the evening? If I had a nickel for every time, I wouldn't be rich, but it probably would have bought me a gallon of gas.
It's not the verbosity strictly speaking. It is the minimal level of abstraction between you and the vcs and it can hardly be helped by a 'nice frontend' when things go wrong. And they will; they always do.
dijit 7 hours ago [-]
Yes, then it breaks because you gave your artist an SSH link to clone and LFS requires a HTTPS auth token and exits with terse errors.
Or, you need to lock your files and git doesn't really support that.
To be fair, your hypothetical is true: UE5 supports Git as a backend, you don't need to run git commands (most of the time), but in practice even in the best circumstances: Git for game dev is brittle, slow, and extremely space inefficient.
Worse still: people try pushing their "short lived branches" workflow when using Git, which is *not* how gamedev works, especially for artists. Longer lived changesets are more common. (in Perforce these are called Shelves).
anigbrowl 8 hours ago [-]
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 8 hours ago [-]
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.
9dev 7 hours ago [-]
and why don't we just follow decades of conventions and add a --verbose/-v flag to display all the gobbledegook if you really want to, but hide it by default? As far as I remember, the guidance has always been "only print something if the user needs to know, no output means success."
git would be perfectly usable without knowing how many objects it has pushed or how fast it was doing so.
1718627440 4 hours ago [-]
Because it is a progress indicator, that you stare at while waiting. Even Youtube does that and that is written for the general population.
genocidicbunny 7 hours ago [-]
That is exactly what one of my earliest CS teachers taught me.
No news is good news.
mvdtnz 8 hours ago [-]
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?
spelunker 11 hours ago [-]
The lights are blinking, so everything must be working!
russdill 9 hours ago [-]
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.
y1n0 8 hours ago [-]
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 34 minutes ago [-]
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.
squirrellous 48 minutes ago [-]
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?
dosshell 10 hours ago [-]
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.
kristjansson 11 hours ago [-]
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
agumonkey 11 hours ago [-]
I actually like this underlying logs. Could have a concise / project level summary though.
gritzko 9 hours ago [-]
Every Beagle command:
gritzko@spot ~/beagle $ be get
19:07 get ?#0ac49e6a
16:58 post ?0ac49e6a#POST-018 put:/post: banner on stdout
19:07 new beagle/test/be-post-put-banner.sh
19:07 upd dog/INDEX.md
...more stuff...
19:07 del test/post/01-bare-msg/01.put.err.txt
19:07 del test/post/01-bare-msg/02.post.err.txt
19:07 get abc?4222dfab
dansmith1919 7 hours ago [-]
This has bothered me ever since I was using git for the first time: what do you mean I have to 'add' and 'commit' and then 'push'? I just want to save my stuff, this is SO many steps.
j_w 6 hours ago [-]
These criticisms of git always seems so shallow to me.
'add' tells git to start tracking some file(s)
'commit' tells git to save the currently tracked files
'push' says "upload my changes to some other location." Git isn't dropbox magically 'rsync'ing the directory to some server.
'pull' says "download any changes from some other location." Same deal as push.
That should satisfy the majority of git casuals that get frustrated with it. You should learn the tools of your trade, and version control (specifically git) is one of the tools of the software trade. If you work adjacent to software why is it so hard to learn a little about git?
yjftsjthsd-h 7 hours ago [-]
You don't have to do add as a separate step unless you're adding it to the repo for the first time. You can (and I do) just `git commit file1 dir2` or whatever. I don't conceptually think commit+push should be combined; committing a version is separate from pushing it to a remote.
abustamam 7 hours ago [-]
TIL! Thanks
abustamam 7 hours ago [-]
When I was getting started with programming I often forgot to do one of those steps and often ended up losing my work because I was working from a library computer or something.
When I got more experience I finally understood why it is like that, and it makes sense now, but its still a lot of steps for someone learning to remember.
minraws 6 hours ago [-]
If you can't understand atleast 70% of those lines of Git, you really should be using a git web app or something.
Or maybe try jj. Either is better than you using Git's raw cli as someone who doesn't really know or care how it works.
Git cli is very much made with rough edges and is generally expected to be in hands of an advanced user, these days lots of commands have been made simpler and stuff, but git cli is just still very raw.
bartvk 8 hours ago [-]
I bet most people don’t use the commandline client.
cedws 12 hours ago [-]
Git as a data structure is clever, but Git as a CLI is atrocious.
VikingCoder 11 hours ago [-]
I feel like, everyone near Git has decided, "Well, all abstractions leak - so we might as well stand in the rain like Andy Dufresne when he escaped from Shawshank Prison!"
1718627440 4 hours ago [-]
But that's all Git originally aspired to be. It was supposed to be the base VCS, that you eventually can build a UI layer on top.
--flaunt-revision=<commit-graph> - Flaunt the revisions of extra commit IDs that are mirrorred.
Is the tool taunting you?
cmrdporcupine 7 hours ago [-]
afaik they're randomly generated so you're likely the first and last person to see that permutation
xiaoyu2006 9 hours ago [-]
this is such a good laugh. peak comedy
raverbashing 12 hours ago [-]
Yes, the famous debate between plumbing and porcelain
Still the porcelain is more like cold stainless steel
mherkender 10 hours ago [-]
I'd rather see some gobbledegook than extended pauses or idealized (read: fake) information. Those are specific tasks it is doing when you run that command, there's a simplicity to it.
Not saying Lore's approach is bad, but sometimes "worse is better".
yomismoaqui 11 hours ago [-]
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)
yoyohello13 11 hours ago [-]
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.
jon-wood 10 hours ago [-]
This is definitely a bit snarky but you read any of the documentation at all, and therefore know more than a large percentage of git users about what it’s actually doing. Most people seem to treat git like some sort of mysterious orb which if you speak the right incantations will perform magic for you.
yoyohello13 10 hours ago [-]
Reading the docs is kind of a superpower for devs. With AI I think most technology is going to be treated like praying to the machine spirit.
1718627440 4 hours ago [-]
If you don't read the documentation you can't complain if a machine stays a mystery for you. Normally you don't get to use a machine without proving you actually now what you are doing.
altmanaltman 10 hours ago [-]
Linus really has very little to do with git's development. He has stated that himself multiple times, and it's the factual truth. "This is what happens when a kernel developer creates tools..." is funny but not factual.
justinhj 8 hours ago [-]
I see Git as a tool aimed at experts that spend time to learn the tool. Asking non technical people to use it is a mistake. You can build guard railed apps on top of it for them, but probably it's the wrong tool.
danudey 9 hours ago [-]
You don't care about any of this information, but that's fine; unless something is going wrong, you can ignore any information that isn't interesting to you.
Having this output is useful for when it does break and you need to copy-paste your terminal output to someone who does understand it to explain it to you or explain how to fix it, but you're correct that 90% of this is effectively debug output that is almost never useful or relevant.
In most cases I would say they should remove any output that isn't necessary, but given that some git operations can be extremely long-running it's beneficial to have some kind of output so the user knows what's going on.
Case in point, this is the output I get when I try to clone the Linux kernel:
Generally not useful information most of the time, but if I didn't have it I would be staring at a blank terminal for an hour wondering what was happening.
Also, I assume you're not but in case anyone is interested in the answers to these questions:
> What the hell is "delta compression"?
The 'delta' is the difference between one thing and another - usually one version of a file and another. Git does some fancy thinking to figure out which files are which other files but with changes, so that it can store just the changes from one version to the next.
For example, a 100 KB file where we only changed 500 bytes ten times would be 1000 KB, but because Git can store the deltas from one to the next it can be 100 KB (the original) plus ten 500-byte changes, for a total of about 105 KB.
> Why do I care how many threads it's using?
Because it directly affects how fast the process works; using 16 threads is 16x faster than using 1 thread (on average). Git automatically detects how many CPU threads are available and uses as many as it can, but if it's being very slow you might look and see 'oh, right, this VM only has two CPUs'.
> What is an 'object' and what does it mean when it's 'local'?
Uh, this one is deliberately vague I guess. An object is a thing that Git keeps track of. Usually this will refer to a blob, which is 'a bunch of bytes that make up a file', or a 'tree', which is a list of files and other trees - basically a directory structure, or a commit's information, but anything that Git keeps track of is an object.
Local just means that you already have a copy on your system. in the 'remote:' line you see output from the other end (where you're pushing to), so that's the server saying that it's using the files it already has.
> What does 'pack-reused' mean?
To be efficient, Git can take all the 'objects' and smush them into one big packfile (rather than having to keep track of hundreds or thousands of separate files). Since Git keeps track of files based on their contents, two identical files are just stored as one copy referenced twice, so it's possible that the file that you're pushing already exists in a pack file and can just be reused rather than having to push another copy.
Melatonic 8 hours ago [-]
The fact you took the time to explain this I think shows the problem. You did an excellent job.
Maybe what we need is one of those infographic things (or several - but not too many) that summarize the main terminology, actions, and basic architecture of how Git works. I've found those usually, when done right, can strike an ideal balance of reaching the largest amount of people. I personally prefer reading tutorials but I know plenty of talented people who instead prefer videos (which I personally hate) and a simple but visually pleasing graphic is right in between.
archerx 12 hours ago [-]
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.
redsocksfan45 11 hours ago [-]
[dead]
yoyohello13 11 hours ago [-]
[flagged]
wldcordeiro 11 hours ago [-]
What a completely rude comment that tells me everything I ever need about you and whether I'd want to interact with you. They're not asking for the literal answer. They're asking a question about why that is important to surface at all.
yoyohello13 11 hours ago [-]
Sorry, you're right. It's been a frustrating morning and I shouldn't have taken it out on you.
tlahtinen 11 hours ago [-]
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 7 hours ago [-]
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.
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.
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 6 hours ago [-]
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.
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.
maccard 5 hours ago [-]
As I said in my last reply - none of that surprises me. Our provider worked out of the box, fwiw.
s1ncere 1 hours ago [-]
This a lot of very old and out of date information and opinions, respectfully disagree
akurilin 6 hours ago [-]
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_ 5 hours ago [-]
They got sold to a private equity company in 2016.
superxpro12 6 hours ago [-]
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 2 hours ago [-]
Its not just about the tech, you have to have non-technical artists using this thing every day
munificent 7 hours ago [-]
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 6 hours ago [-]
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 6 hours ago [-]
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.
akurilin 6 hours ago [-]
Very relatable. I still recall when our team at Microsoft, about 20 years ago, had a dedicated "build engineer" who would be given the task to create a new branch for the product. He would disappear for a few days and re-emerge with the announcement that a new branch had been officially created and was ready to be used. Hard to imagine that in git world.
When I went back to Perforce I was reminded of why that was a thing. You're making a full copy of everything. They recently introduced a virtual copy stream, but I remember people advising against using it, for reasons I can no longer remember. It seemed like a potentially sensible approach.
akurilin 6 hours ago [-]
Oh, and thanks for writing Game Programming Patterns. That was a great resource.
ksec 10 hours ago [-]
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 10 hours ago [-]
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 9 hours ago [-]
I don't see how Rust is more functional programming oriented than C++
MaulingMonkey 9 hours ago [-]
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 9 hours ago [-]
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 7 hours ago [-]
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 8 hours ago [-]
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 8 hours ago [-]
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 7 hours ago [-]
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 12 hours ago [-]
I'd trust this project more if it was named Data.
HansHamster 12 hours ago [-]
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 10 hours ago [-]
If it were Data instead of Lore, it would reject any commit messages that used contractions such as "I'm" and "can't" ;-)
zdw 12 hours ago [-]
Dunno, this seems fully functional?
CommanderData 11 hours ago [-]
Oh brother.
Don't be too hard on Lore.
analog8374 12 hours ago [-]
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 11 hours ago [-]
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].
"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 9 hours ago [-]
I haven't played it since the buyout either, but I'm told it works perfectly with Proton.
LoganDark 8 hours ago [-]
You can no longer use Proton on a Mac (unless you have one of the few models supported by Asahi)
superkuh 9 hours ago [-]
Yes, running the windows version of Rocket League might be possible. But that's not what I bought.
stronglikedan 10 hours ago [-]
> 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 9 hours ago [-]
Could be legal, but it's un ethical
frollogaston 11 hours ago [-]
"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 9 hours ago [-]
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.
penciltwirler 11 hours ago [-]
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!
dimatura 6 hours ago [-]
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 10 minutes ago [-]
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 2 hours ago [-]
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
LtdJorge 10 hours ago [-]
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.
11 hours ago [-]
bschmidt900 4 hours ago [-]
[dead]
fg137 4 hours ago [-]
Is any company going to actually deploy this system, in, let's say, two years?
You can trust Helix and Perforce because they have been doing this for decades, and this is part of their core business. You know they will keep maintaining the products for a while.
But for Epic, they could give up on this project tomorrow, and nothing will happen to their business. If anything, they'll get some dev resources back which helps their business.
It's like why anyone would trust Cloudflare to continue investing in EmDash over the long run. Cloudflare doesn't care about CMS. Their business is not providing the best experience for readers/authors/site owners. It's just a side hustle that is almost irrelevant to their business.
iceweaselfan44 11 hours ago [-]
>fully open source
>look inside
>Lore Desktop Client is available as binaries only, download the installer for your platform here:
> 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 11 hours ago [-]
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 11 hours ago [-]
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.
bogwog 10 hours ago [-]
I was excited about this project, but you convinced me to look into it and yeah, I'm seeing emdashes and overly verbose/elaborate commit messages :(
What a shame
lentil_soup 11 hours ago [-]
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 was and still is a very nice competitor in this space called PlasticSCM. They were bought by Unity a few years ago. Unity has not been a good steward. They should have done what Epic is doing and open sourced it. But instead they chose to give it P&L responsibility. Curious what it's contributing to their financials.
pkasting 10 hours ago [-]
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 10 hours ago [-]
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.)
Git-ish CLI is great. The GUI is more important though. Non-programmers don't want to dabble with CLI. One reason why Perforce is the defacto standard IMO. The GUI covers 99% of daily used operations and is easy to use.
paganartifact 2 hours ago [-]
Lore is copying us with "git for gamedev" messaging, and their entire brand.
Epic interviewed me asking all sorts of questions about my customers and use cases.
"Pagan" "Lore" lol Our site used to say "Folklore" at the top of projects.
They still don't really understand the customer or use case, so have fun.
exac 2 hours ago [-]
I tried your website, but it just says "LOADING".
paganartifact 2 hours ago [-]
It's a regular loading state.
Keep slowly copying other people's ideas without a clue why you are doing it.
Keep losing Fortnite to Roblox and random indie devs. You think copying another person is going to help you? Lol
applfanboysbgon 2 hours ago [-]
Respectfully, "VCS for game development" is not a novel idea in any way, and you have literally zero claim to it. It's obvious that Git is poorly suited for multimedia binaries that are integral to games, so obvious that there's Git LFS which is still just a bolted-on hack when you'd ideally have a system designed for them from scratch. It's also explicitly not specifically "Git for gamedev" -- it's "Perforce for gamedev", as they opt into the authoritative server model rather than Git's decentralized model.
Epic has also been working on this for longer than the three months your repo has been around. This is the launch of the open source project and independent GUI, but it was already integrated with their Fortnite game engine before now.
Your VCS repo is called "Artifact". It seems like a stretch to say that somebody using "Lore" is copying from you. Even if it were called "Pagan" that's still a stretch, but "Artifact" especially so.
I think a VCS written in Javascript is also inherently a nonstarter for any kind of production-grade use case. The idea that nobody else can make a gamedev-oriented VCS because somebody in the world made a little hobby project along those lines is frankly ludicrous.
(Granted, I'm not exactly keen to use Lore myself given the heavy signs of vibe coding throughout the documentation and repo. A vibe coded VCS is also inherently a nonstarter. Here I'm hoping some third party will come along and do VCS for gamedev right!)
I'd also add that there's some element of hypocrisy to criticising Epic here when your own marketing pitch is "I copied Git".
paganartifact 1 hours ago [-]
> I think a VCS written in Javascript is also inherently a nonstarter
That's because you have no clue what it is, or why it's in JavaScript.
Nothing else you said is interesting or valid.
Keep copying other people without a clue why you're doing it. Let's see how many customers you get.
> Fortnite
The only cool thing they did (technically they didn't) - a game that is becoming a platform they can't handle.
> The idea that nobody else can make a gamedev-oriented VCS because somebody in the world made a little hobby project along those lines is frankly ludicrous.
They dropped the "folk" and just made it "lore", it's too close to our branding. It makes no sense for Epic - their site is basically a vibe coded trash version of our real one lol
All Epic does is copy other people, that's why Fortnite sucks now and the company is going downhill.
paganartifact 1 hours ago [-]
Epic is trash. The whole company is basically Tim Sweeney crying on Twitter.
wky 11 hours ago [-]
The link to Architectural Decision Records is empty, but they're present in the repo to look at[0]. Curiously the decision with the most deciders is the implementation of JavaScript bindings[1].
I’ve always wanted a git with five commands, and maybe with AST based diffing
simcop2387 12 hours ago [-]
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.
clone, pull, push, branch, merge, add, commit are the ones I use, but that's 7
10 hours ago [-]
xboxnolifes 8 hours ago [-]
checkout, log, config?
nailer 6 hours ago [-]
And reflog when you make a mistake.
pushcx 12 hours ago [-]
I had wanted the same thing for a long time and jj + difftastic has satisfied me.
jbverschoor 9 hours ago [-]
Too bad it does not support fully local/detached (without server). It would be nice to be able to run it similar to a local repo without remote
ibejoeb 8 hours ago [-]
The unique feature is universal locks (like cvs checkout) for opaque binaries like art, which requires universal state, so this seems to be orthogonal to the goal.
jbverschoor 4 hours ago [-]
Myeah I understand, buy i generally enjoy just creating a local repo. Of course, not what Epic does ;)
dijit 8 hours ago [-]
to be totally fair, perforce doesn’t either.
There are some awkward workarounds (officially supported ones) which create a local server and you then merge with a remote server upstream, but as you might expect: its awkward and practically nothing supports the workflow.
DR_MING 2 hours ago [-]
Can't believe that new version contorl system is coming out, very promising.
speps 12 hours ago [-]
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.
swiftcoder 9 hours ago [-]
I don't see a workflow for locking assets while they are under modification. This is kind of important for assets? Since we don't really have great merge workflows for meshes/animations/sounds/etc.
I also don't see any sort of GUI client? So the whole art team is going to have to get up close and personal with the CLI
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.
armcat 7 hours ago [-]
Can this be used for ML/AI projects as well? I'm thinking for version controlling LoRa finetunes, finetuning data (which can consist of text, images and audio), safetensors, etc?
dimatura 7 hours ago [-]
Of course it can. Is it good at it? I guess we'll find out, for sure people will try (I might if I get some spare time). At a glance some of the tech used resembles that of xethub (of which I was a user, until they got acquired by huggingface), which was marketed towards AI/ML/data science (to version control data/models/etc).
2 hours ago [-]
eblanshey 11 hours ago [-]
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.
> lore stage covers adds, edits, and deletes — you use the same command for all three. Stage a deleted file and Lore records the deletion for the next commit. Moves and renames are tracked too, through a dedicated subcommand: lore stage move <from> <to> records the rename so the file keeps its identity and history across the move instead of registering as a delete plus an add.
Oof. So this isn't compatible with any tools that move or rename files. I can't see how this will be acceptable for real-world use.
xboxnolifes 9 hours ago [-]
Isn't this just the same thing as `git mv`?
ibejoeb 8 hours ago [-]
I don't think so, but I'm not sure. It seems to imply that renaming a file without using `lore stage` subcommands will record a delete and an add, meaning that changes made in a branch prior to the rename won't automatically propagate. Git will detect this without using it's own mv command.
IshKebab 7 hours ago [-]
No they're saying that it will explicitly record the move, unlike Git which has to guess (it often fails).
ibejoeb 7 hours ago [-]
Git does record the move, and you don't have to use the git ui to do it. Lore says it requires `lore stage move` to record it. More details in the reply to your other comment.
IshKebab 8 hours ago [-]
They're actually saying it's better than `git mv`, because it actually records the move, unlike Git.
ibejoeb 8 hours ago [-]
I think they're saying the opposite. It won't detect a filesystem-level move. It will simply record a delete and create without the relationship. Git does record the rename, though:
Git knows that the file was renamed even without using git to do the rename. This means that it doesn't matter if you IDE, codemod, agent, or whatever does it. Git tracks that foo.txt and bar.txt refer to the same blob at different revisions.
Maybe lore does the same, but the docs imply that it doesn't.
--
To summarize: lore will record relationship metadata only when performed with `lore stage move <from> <to>`, so you will have to intervene if your other tooling moves files.
IshKebab 7 hours ago [-]
> Git knows that the file was renamed even without using git to do the rename.
No it doesn't. Git knows that file A was deleted and file B was created, and if they have the same content then it will guess that it was a rename. But it's a heuristic that doesn't always work. E.g. I think it doesn't try to guess for large diffs, and it doesn't work if you modify the file in the same commit.
ibejoeb 7 hours ago [-]
Right, if you rename a file and then change its content without committing it, it doesn't know. Clearly that's bad practice in a multi-user setting because you're going to break all subsequent merges.
However, if you just move or rename a file, git does recognize that, and it doesn't require any manually annotation.
Lore needs you to tell it that you're moving or renaming. It's not the end of the world, but it's a real pain if other tools are operating on the file. You will need to go back and manually annotate those operations if you want it to preserve the relationships.
maccard 6 hours ago [-]
> Lore needs you to tell it that you're moving or renaming. It's not the end of the world, but it's a real pain if other tools are operating on the file. You will need to go back and manually annotate those operations if you want it to preserve the relationships.
Lore is clearly influence by 30 years of epic using perforce, and this is how P4 works.
BoggleOhYeah 12 hours ago [-]
It’s great to finally see a possible alternative to Perforce.
MaikuMori 8 hours ago [-]
I've been working on something like this for internal use for the last 2 month or so. Very high overlap, CAS, version chains, branching available in storage, but not implemented (not as high value for us), file locks, chunked storage on S3 api. Focused on assets only with more focus on build/export (think gh actions for blender files) and QA processes.
Interesting to see where this goes.
Melatonic 8 hours ago [-]
Has anybody used Lore (or the older Epic internal version they were using on Fortnite) for also managing code?
As someone who came from VFX I always found the way Git works to feel very limiting. I feel like it was one of those things that was just so much better than the previous option (SVN, etc) that it blewup without actually being ideal.
yablak 11 hours ago [-]
does anyone have a proper comparison of binary control systems like lore, xet, etc? i'd love to see how it handles mixed case workloads.
gavinhoward 10 hours ago [-]
As someone who has thought a lot about VCS design [1] [2], the chunking approach is the wrong one and will still waste space.
[2]: My WIP VCS has been named Yore for at least two years; I did not copy Lore's name.
MattRix 10 hours ago [-]
This is a very long document that says nothing about chunking at first skim. If chunking is actually wrong, then just explain why, here. Wasting space is not actually a problem if it’s optimized for other purposes instead.
gavinhoward 10 hours ago [-]
When it comes to large assets, wasting large chunks of space is a problem. If your chunks are 64 kib average (from the Lore document), but changes only average 1 kib (which could be a high estimate), then you will still run out of space 64 times faster and need to read 64 times more data off of the disk for certain operations.
It also makes diffing hard, as well as diff viewing.
adrianmonk 8 hours ago [-]
Seems like if Lore wants to reduce space usage, they could apply something like Git's delta compression (as used in packfiles) to the chunks.
Suppose you make a 1 kB change in a 50 MB file. That causes a 64 kB chunk to be created and stored. Disk space is wasted.
But since the 50 MB file was already stored as a sequence of 64 kB chunks, there is an existing 64 kB chunk that is very similar to your new 64 kB chunk. You can store your new chunk as a delta to that, so only ~1 kB of disk space is used.
Admittedly, it's complicated and inelegant. But it allows both deduplication between files (one of the reasons Lore chose chunks, apparently) and efficient space usage for small changes.
frollogaston 10 hours ago [-]
What do you do instead of chunking your snapshots? Storing diffs is usually the other approach.
VikingCoder 9 hours ago [-]
I tried to give that section of the doc a fair read.
Looks like operational transforms to me.
The doc claims it's the first with this technique. A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave. And yes, Google Docs storage works the same way - there are probably papers documenting how efficient Google Docs storage is, but it's not wrapped up in a full VCS that folks can use.
The example in the doc uses text, and unfortunately I think it's for a reason. I think with large, binary game assets, the most common operation is going to be strings of "replace A with B", and depending on your chunk size relative to the distribution of changes you make on your assets, I see it as pretty close to a wash, for efficiency. Especially considering that content-addressable blocks also solves de-duplication, which for a multi-game studio is probably going to be significant. Especially if they're managing multiple releases, patches, development branches, etc.
gavinhoward 5 hours ago [-]
> Looks like operational transforms to me.
Sort of. I add provenance, which helps properly identify collisions, and require a well-defined order by stacking [1] changelists.
> The doc claims it's the first with this technique.
More like the first with the particular angle on the technique. I specifically mention patch theory as another side of the same coin.
> A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave.
Darcs is Pijul's ancestor, and I mentioned Pijul. I also mentioned the weave and how reference sets scale better.
> The example in the doc uses text, and unfortunately I think it's for a reason.
Readability. Nothing more. The real stuff will be a compact binary format.
> I think with large, binary game assets, the most common operation is going to be strings of "replace A with B", and depending on your chunk size relative to the distribution of changes you make on your assets, I see it as pretty close to a wash, for efficiency.
Yore will dedup change data instead because as the Lore document itself identifies, dedupping content is hard using chunks; you either get dedupping or canonical addresses. Change data doesn't have one canonical address; the address is in the commit data instead.
Dedupping changes has another benefit. If most instances are "replace A with B," and A replaces B in multiple places, Yore will be able to store just one instance of A, no matter its size. This matters because the larger the chunk, the less likely it will match any other chunk.
> Especially considering that content-addressable blocks also solves de-duplication, which for a multi-game studio is probably going to be significant. Especially if they're managing multiple releases, patches, development branches, etc.
True, but that should be table stakes. The fact that Git does not is a poor reflection on Git, not an innovation in Lore.
The best answer I have is for you to read the "History Model" section of that design doc through the "Implementing CRDTs" subsection.
LtdJorge 10 hours ago [-]
[flagged]
nyxtom 11 hours ago [-]
I came here hoping Epic Games somehow had launched a reliable alternative to GitHub, but saw their code is hosted on GitHub
manifoldgeo 10 hours ago [-]
Yeah, they should have posted it to LoreHub! I just checked for the availability of lorehub.com, and you can buy it for only ~$13,000 and start a competing business to GitHub.
aayushprime 10 hours ago [-]
I must say lore is an awesome name for a version control system. Much better than git in that regards.
rkagerer 6 hours ago [-]
Is it ironic the first thing I noticed on their landing page was "Find us on GitHub"?
They need a FAQ entry "Why isn't Lore hosted on Lore?"
I think the main reason of the flame wars is the fear the employer will decide to change things and erase all the years of knowledge on the existing tools, by something new. I believe this is the advantage of letting people use different tools for different things.
Qiu_Zhanxuan 8 hours ago [-]
Is it me or I read in the docs "Design System" section that it was made in Scala then I went to double checked again an hour later and it said Rust
bschmidt900 4 hours ago [-]
[dead]
noopprod 11 hours ago [-]
Kind of funny that it's on GitHub no hate.
Missed opportunity for Lorehub.
runevault 4 hours ago [-]
Not really. Lore is for gamedev at companies and so not a distributed VCS. Using it for an open source project if you allow outside PRs makes no sense.
rustyhancock 10 hours ago [-]
Guess this is announced as part of epics state of unreal and if so this is already off to an amazing start even if this is all there is!
samgranieri 9 hours ago [-]
I may not be the first to bring this up, but seeing the name of this program reminds me of Data’s evil brother
mosfets 2 hours ago [-]
I needed it!
nogbit 8 hours ago [-]
Any multiregion deployment requires DynamoDB. Shame this solution is specific to AWS.
dijit 7 hours ago [-]
yeah, that's actually crazy.
I don't know a single AAA (or even AA) studio that hosts Perforce in Cloud at all.
Perforce usually starts out life in a gamedev studio as running on "a spare desktop" which then eventually gets promoted to a real server in a closet.
The most important thing for Perforce is disk, memory and above all: bandwidth (of those things and the network too!); it's also quite latency sensitive since all operations touch the server. So running it far away is never a good idea.
There was some complicated perforce architecture inside Ubisoft to account for this: AAA tends to involve a lot of co-dev studios, so the lead studio would get the commit server and others might get replicas (and you could feel to pain)- but all the perforce instances were actually on the same machines and would replicate to one-another anyway: each project was given a port for the perforce fleet. Really bizarre.
but, that's besides the point. Even the tiny studios run their own locally hosted VCS machines.
Lucasoato 12 hours ago [-]
> 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?
zipy124 11 hours ago [-]
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.
Lucasoato 10 hours ago [-]
Can you tell me where did it break? Or what feature you wished it had? I’m just curious, still trying to form an opinion on this.
frollogaston 11 hours ago [-]
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.
bob1029 11 hours ago [-]
I've used git+LFS for unity projects without much issue. If I was working with more than 2 people, I would definitely reach for something centralized.
10 hours ago [-]
interpol_p 12 hours ago [-]
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
coldpie 12 hours ago [-]
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.
tom_ 11 hours ago [-]
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?))
fwip 12 hours ago [-]
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_duke 9 hours ago [-]
Does this support using S3 as the backing store?
That would be very powerful for various use cases.
samgranieri 9 hours ago [-]
How about the last pre-enshittified version of Minio?
advisedwang 11 hours ago [-]
Nice, this seems sort of like Git-but-for-giant-monorepos. That has been a gap in the opensource VCS market
goolz 9 hours ago [-]
Fantastic. Every time I mix git and games I end up almost having an aneurysm.
bachittle 12 hours ago [-]
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).
armchairhacker 10 hours ago [-]
Game engine, programming language, VCS…will Epic launch a brand new OS?
hparadiz 10 hours ago [-]
As long as Epic Games is anti Linux I will never use any Epic Games product.
Count on it.
ibejoeb 7 hours ago [-]
I'm not a gamer so I'm entirely ignorant of the situation. What's the root of your objection? The games are proprietary, right? So I figure it's not a Stallmanesque position. Is it a big problem to run games on Windows?
hparadiz 7 hours ago [-]
I don't have a Windows install anymore and won't set it up just for one game. Furthermore Epic Games has a history of acquiring studios and them crippling Linux support on games that were already purchased. I have a long list of games that I happily play on Linux with no issues.
ibejoeb 7 hours ago [-]
Didn't know that about Epic. Fair point.
hparadiz 6 hours ago [-]
The way games on Linux work today is most are compiled for Windows. There are a few exceptions like Civ will in many cases provide a fully Linux native build. But even in that case on Linux you can choose whether to run the native or the Windows version.
When you download a Windows game on Steam you will go into the Settings and select "Compatibility Layer" and there you will find several versions of Proton. Proton https://github.com/ValveSoftware/Proton is a pre-configured wine bundled with windows DLLs and Linux .so library files. This makes Proton Immutable for any given major version. Meaning you can run Proton 2.x for your game if that's what fits your situation. It's always there if you need it for your specific games. Steam launches this in a container. It is not emulated. It is a fully native implementation of the API that in many cases achieves superior performance.
This is why you will sometimes see the joke that the most compatible API for Linux is actually the w32 API.
This API is now at the point where pretty much everything works unless you cripple it on purpose. And that's what Epic Games is doing here. There's no technical reason for this. It's a business decision that doesn't even make sense because frankly I could vibe code them a linux native game client that launches their games properly on linux in a few days.
TiredOfLife 10 hours ago [-]
They are so anti linux that they ship a linux version of Lore.
LtdJorge 10 hours ago [-]
Well, that's easy for a Rust binary. But they don't put any effort into having a great UX for Linux devs with Unreal Engine, for example. It barely works on Linux and is almost impossible to run under Wayland.
hparadiz 10 hours ago [-]
They also buy studios and then kill Linux support when it was already working just fine.
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
jon-wood 10 hours ago [-]
This is primarily going to be targeted at Unreal Engine users, for whom the source control tooling they use is the smallest of concerns when it comes to being tied to Epic Games.
MarvinYork 9 hours ago [-]
I wonder how many websites ChatGPT did by now...
Melatonic 8 hours ago [-]
Guessing Tim Sweeney is a Star Trek fan?
ryukoposting 12 hours ago [-]
Hosted onn GitHub. Heh.
Tuna-Fish 12 hours ago [-]
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.
Wowfunhappy 11 hours ago [-]
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.
Karliss 9 hours ago [-]
Git is currently industry standard tool for software development, which means that almost every IDE and code editor has good and mature GIT integration. It will take a while for Lore to achieve similar level of support. Considering the intended usecase seems likely that they focus the effort on integrating into game engines and game development specific needs instead of making plugin for every last code editor. Not only code editor but every other software related tool interacts with version control - code review tools, CI, package managers and code forges. That's a lot more work than just creating a version control system. Why waste effort on areas that already have good alternatives.
Code forges lead to the next reason -> they are making it open source (see the faq for why). If they want community collaboration it makes sense to prefer industry standard tooling. Organization internal consistency doesn't matter to external collaborators. Various Google projects with all their custom tooling are good example of what happens if this gets ignored. Every time I have to deal with depot_tools or repo it's a pain.
Third reason not to self host is that it's not quite production ready (see "Is lore production-ready?" in the FAQ). Can't be self hosting from day 0 and once you have a working setup you need better argument for switching just because you can. If lore was attempting to make a statement that it's a superior method of version control for regular source code it would be a different story.
forrestthewoods 7 hours ago [-]
Frickin sweet.
Perforce is a necessary evil in games. Git is simply not suitable. So this is already a huge win.
I main that Git is - at absolute best - simply mediocre. It's not a "good" VCS tool. It is merely adequate.
I would love to see Epic go for a full Git killer.
It looks like Epic has a created a virtual file system interface that is cross-platform. FRICKIN SWEET. This is a critical component to making a VCS tool that doesn't suck. And there has not been an existing open source solution to it.
ctdinjeu7 5 hours ago [-]
They’re copying Pagan Artifact.
“git for gamedev” they even copied the UI
Surac 10 hours ago [-]
Isnt that what SVN is good for?
sedatk 9 hours ago [-]
Not immutable. Not good with binary files.
Surac 9 hours ago [-]
Interesting. Was‘nt aware of that immutable part. I use it with big bin files for year. Maybe i was lucky
ex-aws-dude 11 hours ago [-]
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
adamnemecek 12 hours ago [-]
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. No GFS is not a solution.
justinhj 8 hours ago [-]
One of the reasons I left the game industry, or at least one the benefits of leaving was to not have to use Perforce any longer. Albeit a necessary evil, hopefully lore is better.
I always wondered if a combination of a database to index assets and asset versions with the data being in S3 style storage would be better for game assets; code can be in Git.
Then your workflows are easy to build on top of that.
boredatoms 10 hours ago [-]
Would lore be good for a tech company monorepo?
Imustaskforhelp 10 hours ago [-]
What sort of scale are we talking about when mentioning tech company's monorepo though?
dankobgd 12 hours ago [-]
never trust epic
CamperBob2 10 hours ago [-]
Why not?
wilg 9 hours ago [-]
I've tried very hard to use Git (with LFS) in both Unity and Unreal and its just been a total disaster of problems for me and the team. Hopefully this can help.
UltimateEdge 12 hours ago [-]
Ahah, the second and third links on the page are to GitHub
echoangle 12 hours ago [-]
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.
MBCook 12 hours ago [-]
It makes total sense. It’s just kind of ironic.
AndriyKunitsyn 12 hours ago [-]
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.
applfanboysbgon 10 hours ago [-]
I'm in the market for a better VCS designed for gamedev-specific concerns, but reading the system design doc, it's LLM-generated. Not exactly confidence inspiring.
LoganDark 12 hours ago [-]
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.
dofm 9 hours ago [-]
So it's more like git in practice than git in principle, I guess.
I am not sure it is much of an issue to implement a centralised system to solve domain-specific problems that are caused by or are in the context of inevitable centralisation.
I can see a bunch of media companies liking this, maybe even small design shops. Quite a lot of CMS and change control work for media is not much more than asset management; version control is often a bit of an afterthought.
Web interfaces to this might end up interesting for non-profits and charities with significant media outreach.
LoganDark 8 hours ago [-]
Clearly this works for Epic Games internally, so it's not an issue. A top-level comment also makes the more appropriate comparison to Perforce.
applfanboysbgon 10 hours ago [-]
It is not a DVCS.
> 3.2 Explicit non-goals¶
> Peer-to-peer decentralization. Lore is centralized by design. Two clients communicate through the remote, not directly.
LoganDark 8 hours ago [-]
Didn't catch that, thanks. I just wanted to point out that 'version control system' does not mean it is like Git, Mercurial, Sapling, etc.
moralestapia 12 hours ago [-]
What a waste of a phenomenal domain name.
Razengan 12 hours ago [-]
My first thought exactly :(
rirze 12 hours ago [-]
I can't imagine it was cheap to acquire it, so any company with VC/big Corp money would've taken it any ways.
11 hours ago [-]
nicebyte 9 hours ago [-]
"Github Repo"
"Find Us on GitHub"
????
gonomodagast 11 hours ago [-]
Why not just use Alienbrain?
1 hours ago [-]
jessinra98 1 hours ago [-]
[dead]
Joshua63 5 hours ago [-]
[dead]
jordand 10 hours ago [-]
[dead]
mamine 2 hours ago [-]
[dead]
Wowfunhappy 2 hours ago [-]
What did I just watch? I am very confused.
DetroitThrow 2 hours ago [-]
Spam from a bot! I think there are automatic filters to prevent this so I'm surprised it wasn't banned before we all had to see it, maybe @dang can comment on how quickly these are supposed to be resolved
Wowfunhappy 2 hours ago [-]
Thanks, I actually thought this had to do with Epic Games somehow!
bschmidt1000 5 hours ago [-]
[dead]
sehw 9 hours ago [-]
[dead]
wullbyte 12 hours ago [-]
[dead]
throwaway613746 11 hours ago [-]
[dead]
yemi43 5 hours ago [-]
[flagged]
gbraad 12 hours ago [-]
What makes lore better or worth considering... when svn and git never failed me...
wongarsu 12 hours ago [-]
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
frollogaston 11 hours ago [-]
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.
koolala 10 hours ago [-]
Is there no git trick to turn off version control on non-text files but still store them? How does Lore handle them better?
LtdJorge 10 hours ago [-]
You still want version control, and locking so that two artists don't concurrently edit the same asset.
bpicolo 12 hours ago [-]
> 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.
gbraad 37 minutes ago [-]
Stating the page initial remarks does not help. Why?
I got my answer when someone mentioned perforce.
gbraad 42 minutes ago [-]
Not sure why the downvotes, as this is a genuine question. In game development svn is often considered due to issues that git has with large files. Just stating what currently is done, and curious to understand what lore improves. Svn is still going strong among many shops.
The comparison with perforce explains more
pdpi 12 hours ago [-]
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.
maccard 6 hours ago [-]
And if your resulting game is 100GB, the source repo was 4TB.
hootz 12 hours ago [-]
Apparently, how it handles binaries when developing games.
gbraad 40 minutes ago [-]
At least a concise argument that makes sense. Not sure why the downforce happened.
Are there any benchmarks/comparisons
HellDunkel 8 hours ago [-]
Why is this ranking #1 on HN? Seems quite niche to me.
headwayoldest 12 hours ago [-]
How long before Epic starts giving away other software and suing git to support lore?
glouwbug 12 hours ago [-]
I can’t remember the last time anyone actually played the game they got for free on epic’s store
WillPostForFood 12 hours ago [-]
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.
argee 10 hours ago [-]
> It is interesting that people are so cynical about Epic giving out free games.
It's a mischaracterization to call the games free, if they require you to install unrelated third-party software you'd rather not install (and which at least in the past has been known to snoop your data without consent). In that sense, you may see it as backlash around characterizing the games as free in the first place, when they obviously are not.
hparadiz 10 hours ago [-]
Does it support Linux?
Tomte 12 hours ago [-]
Kerbal Space Program, Civilization 6, Hogwarts Legacy. All games nobody ever played…
falcor84 11 hours ago [-]
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.
rbits 11 hours ago [-]
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.
tombert 12 hours ago [-]
I play Brotato fairly often. I am not sure I have played any of the other free games I’ve gotten though.
takipsizad 12 hours ago [-]
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)
tombert 11 hours ago [-]
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.
RobotToaster 11 hours ago [-]
I played hogwarts legacy for about an hour before realising it was boring, does that count?
Would love any feedback on it or contributions if people are interested :)
dwroberts 11 hours ago [-]
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.
The issues they want to address are already solved in Diversion (https://diversion.dev). Granted it's not open source yet, but that isn't usually a priority for game/entertainment studios - having a complete platform is.
After tearing it apart for 2 hours - it seems like a solid beginning, but definitely not a fully-functioning product (especially on Mac, I hope it works better on Linux/Windows).
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.
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.
Keys, secrets, etc. yes. But code? What am I missing here?
See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling a joint demonstration of the Radeon card that was going to be in the system, and never partnering with ATI again.
https://web.archive.org/web/20001216031800/https://www.zdnet...
> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.
That's kinda a no-no for partnerships.
People who moved to bluetooth got arguably worse sound quality.
For wired headphones, there were very few lightning headphones and they mostly sucked.
Now with usb-c you can get a broader range of headphones (because other phones have gone with usb-c).
either kind needs a dac inside the dongle, or the shell of the headphone, or have a bulky external dac.
3.5mm is still king for decent wired headphones/earbuds.
Except of course shipping ATI hardware for years afterwards, then also using nvidia, then dropping nvidia and only using ATI/AMD until transitioning to Apple Silicon.
1. They kept existing designs, since even Jobs wasn't so crazy as to demand a complete re-architecture of existing laptop models on a whim; plus they probably also had contractual obligations/pre-purchase arrangements
2. They switched to nvidia, but from everything I know they also hated working with nvidia (IIRC Jobs accused nvidia of stealing Pixar tech)
3. AMD is a different company than ATI (technically), and Apple of that era was different than the Steve Jobs temper tantrum era.
But yes, relevant details.
It's not sensitive in the leaking state secrets sense it's sensitive in the risk adverse lawyers on both sides think it's sensitive.
The Bureaucracy exists to perpetuate the Bureaucracy.
You are looking at the problem from the wrong direction.
If you build a honeypot, to trap hackers, does it behove you to explain what the bait is, and how the trap works?
Know your customer, fraud detection heuristics, finger prints, behavioral triggers are all areas where banks, and financial institutions need to keep the sauce secret. Telling the other party "how" you catch them just gives them the steps of what not to do.
For example say I have a hollowed out wall that is hidden behind a painting.
Just putting my money in the hole is bad once it’s found it’s gone but if I put my money in a safe in the hole. Well now you need to find it and break the safe and a hidden safe is objectively better than just having a safe on the floor because you need to find it first.
Does Gitlab do better with this?
;)
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.
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.
The maximum granularity is also 'per repo'.
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.
Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to:
1. Change the file
2. Commit within the submodule
3. Push the submodule
4. add the submodule change in the outer repo
5. commit in the outer repo
6. push the outer repo
Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.
I'm just asking questions!
If you're making the point that there are multiple confounding factors to just about any non-trivial problem, then I agree.
https://gitolite.com/gitolite/index.html
It has fine-grained permissions but works with regular git clients.
[1] https://gitolite.com/gitolite/overview.html#what-is-gitolite
When you use git submodules, you now have five or six problems.
If you need to NDA the core stuff instead and thus can't pull it as a submodule, the only thing I can think of is to pull the core as binary/compiled artifacts.
That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules
Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.
Git has no built in authentication or RBAC. Thats not what its for. Its flat file source control.
I swear loads of people havent a clue how git works or why it exists...most of the git based cloud services out there are 90% additional crap bolted on.
This is a weak argument you could use for any missing feature.
It’s fine for things that you want devs to be able to see without the Git host being able to see them, it’s less good at RBAC because there’s no real “identity” component at read-time.
Git is bad at such volumes of binary assets, textures, models, sounds, etc.
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.
1: https://gitlab.com/groups/gitlab-org/-/work_items/15061
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.
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.
https://janetgilbert.net/staging/2026/04/27/dealing-with-old...
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.
I had previously worked on a big tech monorepo that has gigabytes of history. It would take forever to clone or do operations on. I had a cheat sheet of git commands that would do things lazily but I forget them (which is the issue).
[1] https://github.com/debarshibasak/assets
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.
1. Code - Git
2. WIP art, shared assets (logos, marketing materials, etc) - Google Drive (because things are often changing, getting passed around, etc)
3. Finished assets (PSD files you're done with, or you think you're done with) - SVN (because we wanted a log of who contributed to what, wanted artists to be able to pick up where someone else left off; having a log of who made changes to a given PSD)
4. Assets rendered out to PNG to include in the app bundle/publish to the static file servers - Git (because those files never changed after being published so the git history wasn't polluted with unneeded files)
I've also used LFS, which is... a fine workaround, but still not great. Users who don't have it configured can still commit binary blobs; users who don't have it configured will clone files incorrectly; if the LFS server is slow, unavailable, unreliable, then the system starts to behave oddly; you need a Git server that supports it.
It was a huge hassle to manage; having a system like this would have been a godsend at that company, and if I still worked there I would be spending all day importing our codebase and assets into it to see how well it works.
SVN makes sense cuz it's done and dusted, but I could see the Drive gettin real messy real fast if things change a lot
(If anyone is about to ask why you would need that many VMs - many companies who do extremely large scale infrastructure! The kind of software where when it breaks it can create a crisis for utilities, governments, healthcare systems, militaries, etc.)
The entire workflow with git avoids huge amounts of the cognitive load of using P4, which in turn means that integration with IDEs becomes much less important.
I worked with P4 around the time I first started learn git (coming to both from SVN). P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git". So glad to be far, far from that particular tool now.
Uhhhhhh. Locking binary assets is ABSOLUTELY NECESSARY in Git. Except Git can't actually do that. So what locking binary assets Git looks like in practice is an unenforced message in Slack saying "hey I'm changing this file please no one else touch it".
Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.
> there is no "merging into streams" equivalent.
Weird take. Streams is Perforce's mediocre take on Git branches. P4 stream merge is close enough to Git branch merge that I would say they're in the same family.
> P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git".
And yet Git has almost zero mind share in gamedev because it doesn't solve the problem.
P4 is somewhat mediocre. And it's made zero improvement in ~8 years since getting bought up by PE.
But I can also teach a game designer or artist who has never heard of source control how to correctly and safely use P4 in about 15 minutes. Meanwhile you can tell Git is badly designed because there are 10,000+ tutorials explaining how easy it is! Spoiler: things that are actually easy do not need 10,000 tutorials telling you that it is easy.
OK, I think this is well-established by up-thread comments, and I don't disagree with it at all (though note that its not just binary assets, it's anything that isn't line oriented, which includes for example XML).
I didn't realize that LinearIO's comment was really that specific; it appeared to be describing general properties of P4 unrelated to the binary issue.
The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say.
I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.
It's "hard to say" if you want to ignore the fact that it requires 10k tutorials. Meanwhile, there are 500+ person companies with non technical users using P4 with literally 0 onboarding other than "by the way, undo is broken don't use it".
> I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.
Using P4 is: Download P4V, install plugin for $EDITOR, and double click on a changelist to submit.
So is it the future now?
In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.
For example:
I can understand how git isn’t always appropriate for less technical workflows and large file sizes, but p4 pain is its own character.
p4 also significantly predates VCSes we consider obsolete. p4 is almost a decade older than SVN.
This is why I wish more command line tools were split into a library that does most of the work and a cli module for purely user interaction. Parsing stdout seems so unnecessary and could be avoided if a program could simply import a library.
- The P4 cpp api was apparently designed before any modern Cpp std lib was available. And is at best archaic, and stringly to use.
- P4 encoding support is pain in the ass to configure. And ensist on adding or removing bom to files.
Delta patches become effortless
If everyone uses it wrong, it was designed wrong. See Q-tips.
It's of almost zero utility, but it does (for me) heighten the beauty and elegance of the concepts behind git (and even, the actual implementation).
https://graphite.com/blog/google-perforce-to-piper-migration
I think you think I'm trying to correct/one-up reactordev. I'm not. I agree with him. He's pointing out throw2ih020 is being ridiculous, and I'm pointing out that it's even more ridiculous because it's less than 3.
While I agree with you, not at Google anymore, I do not consider them the top 3 engine providers that I am referring to in my post. No no, Unreal/Unity/Red/EA/SC it’s all perforce.
Git-annex ?
Edit: I do feel a bit uneasy about epic games, though.
How well does Mercurial work in this situation (or even Subversion, given that Perforce is non-distributed like SVN)?
If perforce is the best there is out there for large binary asset management, then there is a blue ocean worth of potential improvement for git.
Perforce is a piece of crap, a relic of the 20th century that must die in a fiery inferno.
Well, it is intended to compete with Git for version control. It's just that Git happens to be so bad at some aspects of version control that it isn't used much in those cases.
There's no good reason that Git couldn't be good at versioning binary files, or splitting up large projects. I mean people have tried - there's LFS and submodules. It's just that those both suck balls.
I was kind of hoping Jujitsu or Pijul would take a stab at these major Git deficiencies but unfortunately it seems like they are content to do them as badly as Git does.
Git does very well at the 80% and with tools like custom merge tools and git lfs/annex and git sparse "cone" checkouts can get pretty close to hitting the 90 or 95% case.
But yeah, so many of those extra tools in that 80 to 90% area are awful to work with because they aren't the default, aren't out the box, are hard to configure and get right. Partly because it always seems like there will be a gap in that 95%-100% window and partly because the use cases that need that 80% to 90% often are only "just 10% of use cases".
(Which is also to say that to survive Jujitsu and Pijul and others seem to have to work to make sure they handle the 80% base case extremely well just to compete with git, they haven't necessarily time to think about the 90% or 100% problem.)
(ETA: And also relates to why game development seems to feel the 20% cases more, because by volume of data game development is certainly closer to a flip of the 80/20 sides with 80% or more large binaries by volume.)
The only alternative Git offers, which is slightly better IMO, is monorepos. But they're only slightly better - they also have really significant downsides.
I'm 100% sure there's a much nicer solution to the kinds of problems people use submodules for that isn't submodules, but as far as I can tell zero people are trying to find it, despite it being such a universal problem.
* https://github.com/jj-vcs/jj
* https://nest.pijul.com/pijul/pijul
* https://darcs.net/
* https://mercurial-scm.org/
The fact that it was easy to clone a subdirectory was nice; the fact that branches were just subdirectories also was not nice. The fact that tags were mutable since they were also just subdirectories... the fact that every operation you ever did required going to the server (commit, log, checkout, everything) made it a pain if you were on a slow link.
I can't count the number of times I was inspecting SVN history and had to just 'svn log > /tmp/svn.log' so I would have the whole log locally rather than having to hit the server each time I wanted to refine a grep.
I ended up using KDE's SVN migration tool, which was extremely featureful and versatile, as it was designed for the case of moving a massive, complex SVN repository into multiple separate Git repositories, filtering files/directories, importing tags/branches/etc. Saved me a ton of time.
My favourite part was at the end when we migrated the biggest, most important repo, a lot of the original SVN commits were imported from CVS, meaning we had a direct CVS-to-SVN-to-Git migration keeping all of the original metadata from the CVS commits (such as it was). The data purist in me rejoiced.
https://github.com/svn-all-fast-export/svn2git
SVN was actually quite decent for game development, definitely more robust and (non-technical-) user-friendly than git+lfs.
(and SVN isn't really compatible with the work-from-home era unfortunately, you really needed a big server on a gigabit LAN)
Thats not how everyone else works.
We're all using package managers to help with massive amounts of 3rd party dependancies (why are you version pinning in any place other than your repo, why arent you pulling updates through your repo and reviewing them)
We're reliant on tools like artifactory to make sure those depedancys dont disappear or are not corrupted.
We use yet other tools to manage our binary files (this tool would fix that).
Github, gittea, gitlab, bitbucket... have all added piles of tooling around git, that are grafted on around its short comings.
> It's crazy to me that nobody has made anything better yet.
Because our entire industry has fallen into the rut of "more tools", of stacking turtles (https://en.wikipedia.org/wiki/Turtles_all_the_way_down ) rather than fixing the real issues that hold us back.
> Although I could start that myself and yet have not.
Because unless your a Google or a Linus, no one is going to look twice at your tool for something that is this important. Im not even sure that epic games has the good will, or trust to launch this.
I am going to give them the benefit of the doubt and take a long hard look at it, but my optimism is tempered. But unless it offers a LOT more than git, the extra overhead (lacking IDE support, deployment changes and all the other tooling in GIT's orbit) it isnt going to be a worth while change.
This is why I'm not motivated to build something better. I don't think anyone would care.
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.
His criticism isn't limited to AAA game studies. He's a vaccine skeptic and is pretty heavy into far-right influencer garbage. All very surprising if you only know him from his games.
This Tweet is a classic https://x.com/Jonathan_Blow/status/1854708962462982465
Jonathan Blow:
> It doesn't help that all males currently under the age of 40 were raised to be supercucks
I started following him for his gaming work and talks. His influencer content is something else.
Whereas JB actively thinks you're an idiot, and the things you do are idiotic because of your stupidity, period.
I think being influential just does that to people, with high regularity.
Huge teams are more often than not the sign of bloat and inefficiences.
1. https://www.angelcode.com/products/bmfont/
Now there's an argument to be made that many don't need the remaining ones but to claim that you 'replaced PowerPoint' for anyone but yourself is ridiculous.
They're good at demos, I give them that.
I'm wondering if you're confusing Windows terminal with cmd.exe?
Windows terminal is not the shell. It's a terminal emulator. You run a shell inside of the terminal, for example you can run... Powershell.
Command history is a feature of the shell.
https://epicgames.github.io/lore/explanation/system-design/#...
If this supports dynamic hydration of files, either as they're accessed (like Dropbox with offline files) or by somehow knowing which files need which other files (building a dependency graph) then it could be a massive win both for speed and efficiency of downloads but also for conserving disk space on developer machines.
And since it has API bindings, it's possible that's something that could be built into IDE plugins, so that your editor (Godot, Unity, etc) can know which assets need which other assets and automatically trigger hydration, including when you e.g. try to use a new model/texture/etc in a scene that hasn't used it yet.
Also git-lfs is a crutch that breaks more often than it works :/
(I agree though that for small game projects, git is mostly 'good enough', even without lfs).
At Fortinet we migrated our SVN repositories to git and ran into a ton of issues; developers over the past ten years had done tons of little mistakes that added up, like accidentally checking an entire Windows virtual machine into the repo. In SVN they deleted it and no one ended up caring, but in Git of course it became part of the repo history.
I did a huge amount of work for the migration, 99% of which was analyzing each repo to find out what files/file extensions were overly large, and then either:
1. Filtering them out of the git history completely during import
2. Converting them to LFS objects after the import
The LFS process was certainly better than the other alternatives, which were 'check everything into the git history' or 'remove all the un-diffable binary files and hope that they weren't needed for anything', but it was still not ideal.
Every developer (out of thousands, across multiple countries, timezones, and native languages) had to set their system up properly; if you missed a command, or if you reinstalled your OS and forgot to set up one of the aliases or hooks, then you would end up checking binary blobs into git rather than LFS, or checking out LFS idents rather than the actual files they needed.
We also had the issue of developers fetching code over SSH but LFS files over HTTPS, which would be fine except that we wanted to prevent access to HTTPS from most subnets, so while the developers could use SSH to clone or pull using their 2FA token their client would then make an HTTP request that wouldn't work unless they were on the version control VPN, which.... blah blah blah.
So yeah, it worked better than the alternative, but it did not work _well_ a lot of the time.
For the longest time Git tools were really poor. In recent years there's a few ok ones, like Git Fork, though I wouldn't know if those tools scale to the level of a AAA team size repo and not fall over.
it's also tough when you have 1TB of data, over 1mm files and you might want to lock hundreds files in one go
I think branching is the one thing that didn't get more complicated with LFS.
From the documentation, it looks like Lore does a bit better in this regard:
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.
The actual documentation is actually sensible, the issue is just that most people just learn from third parties, who are lax with terms.
> At the end user level, "cache" is only used as an adjective these days; "cached", meaning "contents cached in the index, not the contents in the work tree". We could have called it "indexed", but "cached contents" was an already established phrase from very early days to mean that exact concept, and we did not need another word that meant the same thing.
> There are some commands that take --index and --cached options, and even some that can take both (but not at the same time). Many people find this confusing, but there is a pair of simple rules:
> Here are a handful of examples.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?
There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.
This is very much a "if you don't like X about your country, just move to a different one" kind of "solution". The costs are extreme to the point that pretending it's viable is insulting. Really it's just a way to silence legitimate complaints.
At least they gave us the `--porcelain` flag, meant exactly for this use case, to make the output format of porcelain commands never change. Dumb flag name, though.
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.)
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.)
This is the type of attitude that makes me regret ever commenting on HN.
FFS, git is a tool for programmers.
And I point out the attitude because I've seen it for decades and seen the harm this kind of "it's just harmless extra info" type thinking has brought. I don't know what tone you're reading into it, but I'm quite literally and explicitly criticizing the attitude, not you personally.
We already said it has a garbage UI, you don't need to repeat it
But jokes aside, usually the reason something is considered a "tool for programmers" and not just a tool is because the UI sucks.
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...
Because to me and to the very vast majority of git users it is totally irrelevant.
It is nice that the info is available, but the more sane default would be to hide under a verbose flag not the other way around.
Imagine typing cd folder/ and have the whole filesystem subtree be displayed in the terminal. You are free to ignore it, but it is useless and inconvenient nonetheless
> Imagine typing cd folder
It's not comparable. `cd` is a local command (technically a shell built-in) that completes instantly (unless you cd to a hung NFS mount...). So it honors the Unix philosophy of emitting nothing on success.
But cloning is a network operation. And it's normal for networking tools to output progress by default. See `wget` and `curl`.
The problem with hiding progress under `--verbose` is that by the time you need the information (why is this taking so long?), it's too late to add `--verbose`. You'd have to cancel the command and run it again losing progress.
If you don't want it, then use `--quiet` and move on with your day.
(Sure you could make it smarter by deferring outputting anything until it realizes the operation is taking some time. Patches welcomed.)
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.
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.
One of the things I very frequently heard from the non-programmer disciplines was how obtuse and indecipherable the existing version control systems were. That is where I'm coming from.
Your knowledge is still appreciated, by me as well, because while I am well familiar with the way git works, I have worked with many people who were not, and did not have the time or budget in their minds for understanding it because they had many other concerns. That is what I mean when I said that I worked with some brilliant people -- I could not do even a modicum of what some of them were capable, and likewise they probably weren't capable of the same modicum of what I was doing.
I don't know what specifically the GP post was trying to insinuate, if anything at all, but it resonated with me as someone who had experienced the same thing many times over in my career. And I probably judged your comment a little harshly on first read, which is mea culpa. You provided good information for those newer to git and seeking to understand how it actually works besides the cheat sheet guides you so often find.
> 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.
Precisely, and I think Lore is an interesting proposition for exactly that reason.
You know what's a progress indicator? An actual progress indicator. Not some text telling you such and such process is 1234/5678 steps done...followed by yet another line of text telling you that the process is now at step 3 of 20. It could just be a % indicator with a spinning cursor, unless the -v/-verbose flag is present.
Of course artists can learn to understand what all this means; But that is not their job, they have other things to deal with besides the esoteric and overly verbose CLIs we programmers often make.
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).
I will disagree that the output is too complex; it is. And yes, the large binaries issue is also a huge challenge to it's use. There's only so much time in the day, and when you work in gamedev there are often severe pressures to perform, and spending extra time to get into the weeds of a version control system is often not possible without sacrifice.
Those are not the target market, and that is OK.
> spending extra time to get into the weeds of a version control system is often not possible without sacrifice.
Which is why most Gamedev places use perforce and not git. Or, perhaps now, Lore.
Right up until something goes fucky. You know how many times I got messaged by someone dealing with vcs going wrong for them at a late hour in the evening? If I had a nickel for every time, I wouldn't be rich, but it probably would have bought me a gallon of gas.
It's not the verbosity strictly speaking. It is the minimal level of abstraction between you and the vcs and it can hardly be helped by a 'nice frontend' when things go wrong. And they will; they always do.
Or, you need to lock your files and git doesn't really support that.
To be fair, your hypothetical is true: UE5 supports Git as a backend, you don't need to run git commands (most of the time), but in practice even in the best circumstances: Git for game dev is brittle, slow, and extremely space inefficient.
Worse still: people try pushing their "short lived branches" workflow when using Git, which is *not* how gamedev works, especially for artists. Longer lived changesets are more common. (in Perforce these are called Shelves).
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.
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.
git would be perfectly usable without knowing how many objects it has pushed or how fast it was doing so.
No news is good news.
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.
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.
The git support for new employees drops basically to zero.
I’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push
'add' tells git to start tracking some file(s)
'commit' tells git to save the currently tracked files
'push' says "upload my changes to some other location." Git isn't dropbox magically 'rsync'ing the directory to some server.
'pull' says "download any changes from some other location." Same deal as push.
That should satisfy the majority of git casuals that get frustrated with it. You should learn the tools of your trade, and version control (specifically git) is one of the tools of the software trade. If you work adjacent to software why is it so hard to learn a little about git?
When I got more experience I finally understood why it is like that, and it makes sense now, but its still a lot of steps for someone learning to remember.
Or maybe try jj. Either is better than you using Git's raw cli as someone who doesn't really know or care how it works.
Git cli is very much made with rough edges and is generally expected to be in hands of an advanced user, these days lots of commands have been made simpler and stuff, but git cli is just still very raw.
Still the porcelain is more like cold stainless steel
Not saying Lore's approach is bad, but sometimes "worse is better".
Having this output is useful for when it does break and you need to copy-paste your terminal output to someone who does understand it to explain it to you or explain how to fix it, but you're correct that 90% of this is effectively debug output that is almost never useful or relevant.
In most cases I would say they should remove any output that isn't necessary, but given that some git operations can be extremely long-running it's beneficial to have some kind of output so the user knows what's going on.
Case in point, this is the output I get when I try to clone the Linux kernel:
Generally not useful information most of the time, but if I didn't have it I would be staring at a blank terminal for an hour wondering what was happening.Also, I assume you're not but in case anyone is interested in the answers to these questions:
> What the hell is "delta compression"?
The 'delta' is the difference between one thing and another - usually one version of a file and another. Git does some fancy thinking to figure out which files are which other files but with changes, so that it can store just the changes from one version to the next.
For example, a 100 KB file where we only changed 500 bytes ten times would be 1000 KB, but because Git can store the deltas from one to the next it can be 100 KB (the original) plus ten 500-byte changes, for a total of about 105 KB.
> Why do I care how many threads it's using?
Because it directly affects how fast the process works; using 16 threads is 16x faster than using 1 thread (on average). Git automatically detects how many CPU threads are available and uses as many as it can, but if it's being very slow you might look and see 'oh, right, this VM only has two CPUs'.
> What is an 'object' and what does it mean when it's 'local'?
Uh, this one is deliberately vague I guess. An object is a thing that Git keeps track of. Usually this will refer to a blob, which is 'a bunch of bytes that make up a file', or a 'tree', which is a list of files and other trees - basically a directory structure, or a commit's information, but anything that Git keeps track of is an object.
Local just means that you already have a copy on your system. in the 'remote:' line you see output from the other end (where you're pushing to), so that's the server saying that it's using the files it already has.
> What does 'pack-reused' mean?
To be efficient, Git can take all the 'objects' and smush them into one big packfile (rather than having to keep track of hundreds or thousands of separate files). Since Git keeps track of files based on their contents, two identical files are just stored as one copy referenced twice, so it's possible that the file that you're pushing already exists in a pack file and can just be reused rather than having to push another copy.
Maybe what we need is one of those infographic things (or several - but not too many) that summarize the main terminology, actions, and basic architecture of how Git works. I've found those usually, when done right, can strike an ideal balance of reaching the largest amount of people. I personally prefer reading tutorials but I know plenty of talented people who instead prefer videos (which I personally hate) and a simple but visually pleasing graphic is right in between.
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.)
https://github.com/EpicGames/UnrealEngine/pull/14630
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/
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.
> 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...
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.
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.
When I went back to Perforce I was reminded of why that was a thing. You're making a full copy of everything. They recently introduced a virtual copy stream, but I remember people advising against using it, for reasons I can no longer remember. It seemed like a potentially sensible approach.
>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.
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.
It also borrows a lot of features from FP languages like nice tagged unions (enums), Result, everything-is-an-expression, etc.
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.
Don't be too hard on Lore.
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...
(Trek) Data is Lore constrained to, what? Convention?
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.
- 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!
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.
That already warrants different storage architectures.
You can trust Helix and Perforce because they have been doing this for decades, and this is part of their core business. You know they will keep maintaining the products for a while.
But for Epic, they could give up on this project tomorrow, and nothing will happen to their business. If anything, they'll get some dev resources back which helps their business.
It's like why anyone would trust Cloudflare to continue investing in EmDash over the long run. Cloudflare doesn't care about CMS. Their business is not providing the best experience for readers/authors/site owners. It's just a side hustle that is almost irrelevant to their business.
> 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.
What a shame
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"
I expect fully to mean fully, though.
Passing for now.
Looks very git-ish. But probably better equipped for large binary files.
Epic interviewed me asking all sorts of questions about my customers and use cases.
"Pagan" "Lore" lol Our site used to say "Folklore" at the top of projects.
They still don't really understand the customer or use case, so have fun.
Keep slowly copying other people's ideas without a clue why you are doing it.
Keep losing Fortnite to Roblox and random indie devs. You think copying another person is going to help you? Lol
Epic has also been working on this for longer than the three months your repo has been around. This is the launch of the open source project and independent GUI, but it was already integrated with their Fortnite game engine before now.
Your VCS repo is called "Artifact". It seems like a stretch to say that somebody using "Lore" is copying from you. Even if it were called "Pagan" that's still a stretch, but "Artifact" especially so.
I think a VCS written in Javascript is also inherently a nonstarter for any kind of production-grade use case. The idea that nobody else can make a gamedev-oriented VCS because somebody in the world made a little hobby project along those lines is frankly ludicrous.
(Granted, I'm not exactly keen to use Lore myself given the heavy signs of vibe coding throughout the documentation and repo. A vibe coded VCS is also inherently a nonstarter. Here I'm hoping some third party will come along and do VCS for gamedev right!)
I'd also add that there's some element of hypocrisy to criticising Epic here when your own marketing pitch is "I copied Git".
That's because you have no clue what it is, or why it's in JavaScript.
Nothing else you said is interesting or valid.
Keep copying other people without a clue why you're doing it. Let's see how many customers you get.
> Fortnite
The only cool thing they did (technically they didn't) - a game that is becoming a platform they can't handle.
> The idea that nobody else can make a gamedev-oriented VCS because somebody in the world made a little hobby project along those lines is frankly ludicrous.
They dropped the "folk" and just made it "lore", it's too close to our branding. It makes no sense for Epic - their site is basically a vibe coded trash version of our real one lol
All Epic does is copy other people, that's why Fortnite sucks now and the company is going downhill.
[0] https://github.com/EpicGames/lore/tree/main/docs/developing/...
[1] https://github.com/EpicGames/lore/blob/main/docs/developing/...
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
https://replicated.wiki/blog/uris.html
There are some awkward workarounds (officially supported ones) which create a local server and you then merge with a remote server upstream, but as you might expect: its awkward and practically nothing supports the workflow.
I also don't see any sort of GUI client? So the whole art team is going to have to get up close and personal with the CLI
GUI: https://epicgames.github.io/lore/faq/#does-lore-have-a-deskt...
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.
[0] https://github.com/eblanshey/HistoryWorkbench
Oof. So this isn't compatible with any tools that move or rename files. I can't see how this will be acceptable for real-world use.
Maybe lore does the same, but the docs imply that it doesn't.
--
To summarize: lore will record relationship metadata only when performed with `lore stage move <from> <to>`, so you will have to intervene if your other tooling moves files.
No it doesn't. Git knows that file A was deleted and file B was created, and if they have the same content then it will guess that it was a rename. But it's a heuristic that doesn't always work. E.g. I think it doesn't try to guess for large diffs, and it doesn't work if you modify the file in the same commit.
However, if you just move or rename a file, git does recognize that, and it doesn't require any manually annotation.
Lore needs you to tell it that you're moving or renaming. It's not the end of the world, but it's a real pain if other tools are operating on the file. You will need to go back and manually annotate those operations if you want it to preserve the relationships.
Lore is clearly influence by 30 years of epic using perforce, and this is how P4 works.
Interesting to see where this goes.
As someone who came from VFX I always found the way Git works to feel very limiting. I feel like it was one of those things that was just so much better than the previous option (SVN, etc) that it blewup without actually being ideal.
[1]: https://gavinhoward.com/uploads/designs/yore.md
[2]: My WIP VCS has been named Yore for at least two years; I did not copy Lore's name.
It also makes diffing hard, as well as diff viewing.
Suppose you make a 1 kB change in a 50 MB file. That causes a 64 kB chunk to be created and stored. Disk space is wasted.
But since the 50 MB file was already stored as a sequence of 64 kB chunks, there is an existing 64 kB chunk that is very similar to your new 64 kB chunk. You can store your new chunk as a delta to that, so only ~1 kB of disk space is used.
Admittedly, it's complicated and inelegant. But it allows both deduplication between files (one of the reasons Lore chose chunks, apparently) and efficient space usage for small changes.
Looks like operational transforms to me.
The doc claims it's the first with this technique. A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave. And yes, Google Docs storage works the same way - there are probably papers documenting how efficient Google Docs storage is, but it's not wrapped up in a full VCS that folks can use.
The example in the doc uses text, and unfortunately I think it's for a reason. I think with large, binary game assets, the most common operation is going to be strings of "replace A with B", and depending on your chunk size relative to the distribution of changes you make on your assets, I see it as pretty close to a wash, for efficiency. Especially considering that content-addressable blocks also solves de-duplication, which for a multi-game studio is probably going to be significant. Especially if they're managing multiple releases, patches, development branches, etc.
Sort of. I add provenance, which helps properly identify collisions, and require a well-defined order by stacking [1] changelists.
> The doc claims it's the first with this technique.
More like the first with the particular angle on the technique. I specifically mention patch theory as another side of the same coin.
> A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave.
Darcs is Pijul's ancestor, and I mentioned Pijul. I also mentioned the weave and how reference sets scale better.
> The example in the doc uses text, and unfortunately I think it's for a reason.
Readability. Nothing more. The real stuff will be a compact binary format.
> I think with large, binary game assets, the most common operation is going to be strings of "replace A with B", and depending on your chunk size relative to the distribution of changes you make on your assets, I see it as pretty close to a wash, for efficiency.
Yore will dedup change data instead because as the Lore document itself identifies, dedupping content is hard using chunks; you either get dedupping or canonical addresses. Change data doesn't have one canonical address; the address is in the commit data instead.
Dedupping changes has another benefit. If most instances are "replace A with B," and A replaces B in multiple places, Yore will be able to store just one instance of A, no matter its size. This matters because the larger the chunk, the less likely it will match any other chunk.
> Especially considering that content-addressable blocks also solves de-duplication, which for a multi-game studio is probably going to be significant. Especially if they're managing multiple releases, patches, development branches, etc.
True, but that should be table stakes. The fact that Git does not is a poor reflection on Git, not an innovation in Lore.
[1]: https://www.stacking.dev/
They need a FAQ entry "Why isn't Lore hosted on Lore?"
Helpful page that gets closer to the details
Missed opportunity for Lorehub.
I don't know a single AAA (or even AA) studio that hosts Perforce in Cloud at all.
Perforce usually starts out life in a gamedev studio as running on "a spare desktop" which then eventually gets promoted to a real server in a closet.
The most important thing for Perforce is disk, memory and above all: bandwidth (of those things and the network too!); it's also quite latency sensitive since all operations touch the server. So running it far away is never a good idea.
There was some complicated perforce architecture inside Ubisoft to account for this: AAA tends to involve a lot of co-dev studios, so the lead studio would get the commit server and others might get replicas (and you could feel to pain)- but all the perforce instances were actually on the same machines and would replicate to one-another anyway: each project was given a port for the perforce fleet. Really bizarre.
but, that's besides the point. Even the tiny studios run their own locally hosted VCS machines.
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?
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.
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?))
That would be very powerful for various use cases.
Count on it.
When you download a Windows game on Steam you will go into the Settings and select "Compatibility Layer" and there you will find several versions of Proton. Proton https://github.com/ValveSoftware/Proton is a pre-configured wine bundled with windows DLLs and Linux .so library files. This makes Proton Immutable for any given major version. Meaning you can run Proton 2.x for your game if that's what fits your situation. It's always there if you need it for your specific games. Steam launches this in a container. It is not emulated. It is a fully native implementation of the API that in many cases achieves superior performance.
This is why you will sometimes see the joke that the most compatible API for Linux is actually the w32 API.
This API is now at the point where pretty much everything works unless you cripple it on purpose. And that's what Epic Games is doing here. There's no technical reason for this. It's a business decision that doesn't even make sense because frankly I could vibe code them a linux native game client that launches their games properly on linux in a few days.
From the horses mouth itself:
https://x.com/timsweeneyepic/status/964284402741149698?lang=...
He straight up makes fun of Linux because he hates Valve and GabeN.
https://x.com/TimSweeneyEpic/status/2054680825677910439?s=20
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
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.
Code forges lead to the next reason -> they are making it open source (see the faq for why). If they want community collaboration it makes sense to prefer industry standard tooling. Organization internal consistency doesn't matter to external collaborators. Various Google projects with all their custom tooling are good example of what happens if this gets ignored. Every time I have to deal with depot_tools or repo it's a pain.
Third reason not to self host is that it's not quite production ready (see "Is lore production-ready?" in the FAQ). Can't be self hosting from day 0 and once you have a working setup you need better argument for switching just because you can. If lore was attempting to make a statement that it's a superior method of version control for regular source code it would be a different story.
Perforce is a necessary evil in games. Git is simply not suitable. So this is already a huge win.
I main that Git is - at absolute best - simply mediocre. It's not a "good" VCS tool. It is merely adequate.
I would love to see Epic go for a full Git killer.
It looks like Epic has a created a virtual file system interface that is cross-platform. FRICKIN SWEET. This is a critical component to making a VCS tool that doesn't suck. And there has not been an existing open source solution to it.
“git for gamedev” they even copied the UI
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
I always wondered if a combination of a database to index assets and asset versions with the data being in S3 style storage would be better for game assets; code can be in Git. Then your workflows are easy to build on top of that.
I am not sure it is much of an issue to implement a centralised system to solve domain-specific problems that are caused by or are in the context of inevitable centralisation.
I can see a bunch of media companies liking this, maybe even small design shops. Quite a lot of CMS and change control work for media is not much more than asset management; version control is often a bit of an afterthought.
Web interfaces to this might end up interesting for non-profits and charities with significant media outreach.
> 3.2 Explicit non-goals¶
> Peer-to-peer decentralization. Lore is centralized by design. Two clients communicate through the remote, not directly.
????
I got my answer when someone mentioned perforce.
The comparison with perforce explains more
Are there any benchmarks/comparisons
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.
It's a mischaracterization to call the games free, if they require you to install unrelated third-party software you'd rather not install (and which at least in the past has been known to snoop your data without consent). In that sense, you may see it as backlash around characterizing the games as free in the first place, when they obviously are not.
But Kojima games require me to be in a very specific mood and I have been trying to work my way up to it.
Would love any feedback on it or contributions if people are interested :)
https://en.wikipedia.org/wiki/Open-core_model
After tearing it apart for 2 hours - it seems like a solid beginning, but definitely not a fully-functioning product (especially on Mac, I hope it works better on Linux/Windows).
Disclaimer - I'm one of Diversion's founders.