17 ms·

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 competit

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 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.

yemi43 4mo ago
[flagged]
rootlocus 4mo 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 4mo 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 4mo ago
    Permissions is another thing. Git permissions are done one a per repo basis. https://epicgames.github.io/lore/explanation/system-design/#251-lore-vs-git https://epicgames.github.io/lore/explanation/system-design/#...
  - danudey 4mo ago
    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 4mo 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.
- lentil_soup 4mo 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 4mo 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.
    - lentil_soup 4mo ago
      No, I meant the locking. Being able to branch a lock so you can edit an asset in a feature branch and then discard it (or force a merge)
- zipy124 4mo 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 4mo 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.
- flohofwoe 4mo 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).
- Tiktaalik 4mo 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.
  - Scramblejams 4mo ago
    Maybe more than a headwind. From my time in AAA here are two things I learned that were true in that environment: 1. Artists hate Perforce. 2. You will never get them to try anything else. I'm exaggerating, but not by that much. I lost count of the number of artists who are deeply uncomfortable with technology and just manage to learn the bare minimum to do their job, and then will take no more. So besides everything else Lore needs to nail to be acceptable, they need to make it easy for artists to switch. Maybe when UnrealGameSync grows enough knobs and switches to make it unnecessary for an artist to ever touch P4V, Epic can roll Lore into UGS as an unobtrusive option. And if by then there's good support in Unity, in JetBrains, in Maya, etc., then maybe they'll have something.
chadgpt3 4mo 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 4mo 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 4mo 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."
    - chadgpt3 4mo ago
      Isn't that kind of the point though? Doing more with less?
    - Aurornis 4mo 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 4mo 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.
LugosFergus 4mo 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.
- stevefan1999 4mo 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 4mo 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 4mo 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.
TheBigSalad 4mo 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.
- VorpalWay 4mo ago
  There are some projects: * https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj * https://nest.pijul.com/pijul/pijul https://nest.pijul.com/pijul/pijul
  - F3nd0 4mo ago
    Also some older but still kicking alternatives: * https://darcs.net/ https://darcs.net/ * https://mercurial-scm.org/ https://mercurial-scm.org/
- jaapz 4mo ago
  turns out version control is hard
- devin 4mo ago
  With respect, were you around to use any of its predecessors?
  - deleted 4mo ago
    [deleted]
  - bigstrat2003 4mo 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 4mo 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.
Decabytes 4mo 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 4mo 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 4mo ago
    Can you name five?
    - 827a 4mo ago
      Kubernetes and the one I'm working at right now.
      - throw2ih020 4mo 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 4mo ago
  [flagged]
ur-whale 4mo 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.
- maccard 4mo 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 4mo ago
  15 years ago, both Google and Microsoft were on perforce. (The latter through a fork with a different name.)
  - kps 4mo 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`.
- danudey 4mo 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.
debarshri 4mo ago
I am building a small asset heavy game. Ran into a similar problem. Built a storage cost efficient tool for exactly this [1]. [1] https://github.com/debarshibasak/assets https://github.com/debarshibasak/assets
- GabeIsko 4mo ago
  Man, I always hoped to find a project like this on hackernews. I starred it.
kvirani 4mo 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 4mo 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.
  - red-iron-pine 4mo 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
  - maccard 4mo ago
    Yeah that seems like an awful solution. This is exactly why we use perforce and just shove _everything_ in it.
  - 4mo ago
retroflexzy 4mo ago
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.
- arka2147483647 4mo 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.
throwaway81523 4mo 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 ?
- throw2ih020 4mo ago
  You gave me a flashback to that time I tried to use Git Annex on a moderately sized dataset and it resulted in a sysadmin at rsync.net personally contacting me to see if I needed help with whatever poorly written script was hammering their service. In other words: No, absolutely not.
LinearIO 4mo 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 4mo 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 4mo ago
    Solving merge conflicts on text-based files is infinitely easier than binary-based. It's not a useful comparison.
    - PaulDavisThe1st 4mo 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?
      - gmueckl 4mo ago
        Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.
jayd16 4mo ago
P4 is more "industry standard" than "state of the art"... But it does handle large files and partial checkouts without feeling bolted on.
- Hendrikto 4mo ago
  Git has had native partial checkout for ages.
  - oblio 4mo ago
    > partial checkouts without feeling bolted on. OP said this, maybe Perforce's partial checkouts are just better than Git's.
  - jayd16 4mo ago
    Do you know any large, non-technical teams that use it? The workflow is just not feasible even if the feature technically exist. Things like submodules become even more complex. Without submodules there's no equivalent to map in library/engine code into place in a way where you can push changes back upstream. Last I checked, things like logs and pulling still operate on every commit so it doesn't really scale the same way.
manoDev 4mo 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 4mo ago
  One of those ideas that sounds clever in theory but in reality doesn’t work very well
  - bigbuppo 4mo ago
    Also... it's kind of weird taking a decentralized system and recentralizing it.
    - bbkane 4mo ago
      Isn't centralizing systems over time more common than not? Another example is the Internet: websites do not have a uniform distribution of traffic
- deleted 4mo ago
  [deleted]
arka2147483647 4mo 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.
- cylemons 4mo ago
  Yikes, does that mean each dev has terabytes of stuff on their machine?
  - badsectoracula 4mo ago
    Theoretically yes, but in practice you don't need the full repository, but even in mid-2010 (when i first encounter Perforce in a gamedev company - previously the companies i worked on used Subversion which was also able to handle some huge repositories -- one had all their games from the 90s to early 2010s in a single Svn repository, including code and data) a workspace with just the game's code and data in the engine's format (i.e. excluding everything a programmer wouldn't need, like the "source data" for assets such as max/maya/etc files) was around 250GB or so. IIRC the entire repository (all versions, not just latest) had crossed a petabyte in size :-P though that company put absolutely everything in Perforce.
  - throw2ih020 4mo ago
    If they're doing a full build then yes, but in practice most devs or artists will work on smaller partial checkouts and another engineer or team works to keep everything integrated into regular builds. You don't need the full game locally to rig a model or paint a texture, and even some gameplay stuff can be tested in a graybox demo environment without the full game assets before being integrated.
reactordev 4mo ago
Has nothing to do with Perforce being the Oracle of VCS because it’s baked into the big 3? Riiiight.
- jhatemyjob 4mo ago
  It's not even baked into Google anymore.
  - Arainach 4mo 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. https://graphite.com/blog/google-perforce-to-piper-migration https://graphite.com/blog/google-perforce-to-piper-migration
    - jhatemyjob 4mo ago
      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 4mo 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 4mo 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.
ultrahax 4mo ago
Can confirm, we have a team dedicated to the care and feeding of p4.
raincole 4mo 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. 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 4mo 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.
  - fc417fc802 4mo ago
    > Now we can rewrite the history of the LFS repo on an as-needed basis. With the giant caveat that doing this effectively breaks the history of the parent project. TBF that's not really any different than rewriting history and later discovering that an old version of a lockfile no longer works but I still think it's worth mentioning.
    - Marsymars 4mo ago
      Yeah, I can't edit my first post, but should note that if you don't want to rewrite history of the submodule, it also at least lets you consistently do shallow clones of the submodule - various git-related CI/CD operations on the main repo won't work with shallow clones, so it's a pain if you have to pull in a million old versions of binary dependencies just to run gitversion. As far as rewriting the history of the submodule goes... that's really something we're okay with - for us, the alternative to the git submobdule was just an SMB share - indefinitely keeping old binary dependencies isn't something we want to do.
IshKebab 4mo 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 4mo 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.)
  - IshKebab 4mo 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.
j1elo 4mo ago
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.
slowmovintarget 4mo 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.
throw0101c 4mo 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 4mo ago
  Mercurial is a bit better, but not by much it had slightly better large file support historically but I wouldn't recommend it.
DonHopkins 4mo ago
Git LFS causes nothing but pain, suffering, and regret.
- GabeIsko 4mo ago
  I braced myself for this, and instead found that it worked surprisingly well for my uses. I only manage 4 gigs though.
Calgaryp 4mo 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.
bc1000003 4mo 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 4mo 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. 1: https://gitlab.com/groups/gitlab-org/-/work_items/15061 https://gitlab.com/groups/gitlab-org/-/work_items/15061
- maccard 4mo ago
  > Perforce does get the job done and it's reliable and stable. Well… perforce does get the job done, but it does need a lot of hand holding from an admin (and you need someone who knows p4 server if you’re using it). It’s also stable in the sense of “it has exactly the same feature set as it did 15 years ago, and branches (streams) are considered modern”.
MayeulC 4mo 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.
apatheticonion 4mo 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 4mo ago
  There's `--filter=blob:none` and it allows to automatically fetch blobs when needed.
  - apatheticonion 4mo 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).
woctordho 4mo 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.
- StellarScience 4mo ago
  10 months or so ago I believe HN posted "The future of Large Files in Git is Git" : https://tylercipriani.com/blog/2025/08/15/git-lfs/ https://tylercipriani.com/blog/2025/08/15/git-lfs/ So is it the future now?
left-struck 4mo ago
Can this be used for Solidworks models? PDM is so awful
- throw2ih020 4mo ago
  Yeah, engineering is another use case for Perforce, will be interesting to see if Epic pursues that market too. I know UE has some use in industries like architecture and professional simulators.
toobulkeh 4mo ago
Why do you need to lock anything? To prevent someone else from working on it? To prevent duplicative work? That sounds like a management/coordination issue. Not a VCS issue. So you have version A and version B. Why are 2 artists working on the same asset without coordination? Do they not use task tracking or project management? Even if that’s ignored, then one person’s work gets wasted. That happens all the time in text based dev too if it’s lacking coordination. Should coordination live in the VCS layer? That sounds like it creates more issues than prevents.
- lentil_soup 4mo ago
  Because it's not so cleanly cut. Editing a level might touch several files without you realising, you might move a mesh file which causes 100s of references to update across 100s of files. For example, you want several people collaborating on a level. Say a level designer, an artist, a lighting person, audio. Usually you split this into several files to allow for the collab but you're bound to hit moments where you need to edit across the board. The level designer moves an area which causes the light, audio, meshes to move. If you don't have a way of knowing someone else is working on those files you're going to step on a lot of toes. Whether this should live separately from source control is a fair question, but it's just a simple place for it as it's tied directly to the files. Also, the outcome of a mistake is quite high, it could mean a whole day or two (a week?) of wasted work because you didn't realise someone was also editing the same file.
tikotus 4mo ago
I like putting it like this: VCS can be centralized or decentralized, and it can version per file or per commit. For games you want centralized per file versioning, like Perforce. Git is decentralized per commit versioning.
- maccard 4mo ago
  I mostly agree. I think for games you want per commit versioning 95% of the time. You don’t _really want developers building with cherry picked old revisions etc, but you don’t want an artist to have to pull down the 8TB of new art content that was submitted in the last 48 hours to update a texture.. the only way to do that is per file versioning!
  - tikotus 4mo ago
    Indeed. But luckily those who mostly want per commit versioning are coders, and they are technical enough to find a solution for this. Like perforce git interface.

yemi43 4mo ago

[flagged]

rootlocus 4mo 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 4mo 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 4mo ago
  Permissions is another thing. Git permissions are done one a per repo basis. https://epicgames.github.io/lore/explanation/system-design/#251-lore-vs-git https://epicgames.github.io/lore/explanation/system-design/#...
- danudey 4mo ago
  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 4mo 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.
lentil_soup 4mo 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 4mo 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.
  - lentil_soup 4mo ago
    No, I meant the locking. Being able to branch a lock so you can edit an asset in a feature branch and then discard it (or force a merge)
zipy124 4mo 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 4mo 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.
flohofwoe 4mo 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).
Tiktaalik 4mo 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.
- Scramblejams 4mo ago
  Maybe more than a headwind. From my time in AAA here are two things I learned that were true in that environment: 1. Artists hate Perforce. 2. You will never get them to try anything else. I'm exaggerating, but not by that much. I lost count of the number of artists who are deeply uncomfortable with technology and just manage to learn the bare minimum to do their job, and then will take no more. So besides everything else Lore needs to nail to be acceptable, they need to make it easy for artists to switch. Maybe when UnrealGameSync grows enough knobs and switches to make it unnecessary for an artist to ever touch P4V, Epic can roll Lore into UGS as an unobtrusive option. And if by then there's good support in Unity, in JetBrains, in Maya, etc., then maybe they'll have something.

chadgpt3 4mo 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 4mo 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 4mo 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."
  - chadgpt3 4mo ago
    Isn't that kind of the point though? Doing more with less?
  - Aurornis 4mo 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 4mo 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.

LugosFergus 4mo 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.

stevefan1999 4mo 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 4mo 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 4mo 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.

TheBigSalad 4mo 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.

VorpalWay 4mo ago
There are some projects: * https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj * https://nest.pijul.com/pijul/pijul https://nest.pijul.com/pijul/pijul
- F3nd0 4mo ago
  Also some older but still kicking alternatives: * https://darcs.net/ https://darcs.net/ * https://mercurial-scm.org/ https://mercurial-scm.org/
jaapz 4mo ago
turns out version control is hard
devin 4mo ago
With respect, were you around to use any of its predecessors?
- deleted 4mo ago
  [deleted]
- bigstrat2003 4mo 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 4mo 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.

Decabytes 4mo 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 4mo 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 4mo ago
  Can you name five?
  - 827a 4mo ago
    Kubernetes and the one I'm working at right now.
    - throw2ih020 4mo 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 4mo ago
[flagged]

ur-whale 4mo 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.

maccard 4mo 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 4mo ago
15 years ago, both Google and Microsoft were on perforce. (The latter through a fork with a different name.)
- kps 4mo 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`.
danudey 4mo 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.

debarshri 4mo ago

I am building a small asset heavy game. Ran into a similar problem. Built a storage cost efficient tool for exactly this [1]. [1] https://github.com/debarshibasak/assets https://github.com/debarshibasak/assets

GabeIsko 4mo ago
Man, I always hoped to find a project like this on hackernews. I starred it.

kvirani 4mo 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 4mo 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.
- red-iron-pine 4mo 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
- maccard 4mo ago
  Yeah that seems like an awful solution. This is exactly why we use perforce and just shove _everything_ in it.
- 4mo ago

retroflexzy 4mo ago

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.

arka2147483647 4mo 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.

throwaway81523 4mo 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 ?

throw2ih020 4mo ago
You gave me a flashback to that time I tried to use Git Annex on a moderately sized dataset and it resulted in a sysadmin at rsync.net personally contacting me to see if I needed help with whatever poorly written script was hammering their service. In other words: No, absolutely not.

LinearIO 4mo 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 4mo 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 4mo ago
  Solving merge conflicts on text-based files is infinitely easier than binary-based. It's not a useful comparison.
  - PaulDavisThe1st 4mo 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?
    - gmueckl 4mo ago
      Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.

jayd16 4mo ago

P4 is more "industry standard" than "state of the art"... But it does handle large files and partial checkouts without feeling bolted on.

Hendrikto 4mo ago
Git has had native partial checkout for ages.
- oblio 4mo ago
  > partial checkouts without feeling bolted on. OP said this, maybe Perforce's partial checkouts are just better than Git's.
- jayd16 4mo ago
  Do you know any large, non-technical teams that use it? The workflow is just not feasible even if the feature technically exist. Things like submodules become even more complex. Without submodules there's no equivalent to map in library/engine code into place in a way where you can push changes back upstream. Last I checked, things like logs and pulling still operate on every commit so it doesn't really scale the same way.

manoDev 4mo 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 4mo ago
One of those ideas that sounds clever in theory but in reality doesn’t work very well
- bigbuppo 4mo ago
  Also... it's kind of weird taking a decentralized system and recentralizing it.
  - bbkane 4mo ago
    Isn't centralizing systems over time more common than not? Another example is the Internet: websites do not have a uniform distribution of traffic
deleted 4mo ago
[deleted]

arka2147483647 4mo 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.

cylemons 4mo ago
Yikes, does that mean each dev has terabytes of stuff on their machine?
- badsectoracula 4mo ago
  Theoretically yes, but in practice you don't need the full repository, but even in mid-2010 (when i first encounter Perforce in a gamedev company - previously the companies i worked on used Subversion which was also able to handle some huge repositories -- one had all their games from the 90s to early 2010s in a single Svn repository, including code and data) a workspace with just the game's code and data in the engine's format (i.e. excluding everything a programmer wouldn't need, like the "source data" for assets such as max/maya/etc files) was around 250GB or so. IIRC the entire repository (all versions, not just latest) had crossed a petabyte in size :-P though that company put absolutely everything in Perforce.
- throw2ih020 4mo ago
  If they're doing a full build then yes, but in practice most devs or artists will work on smaller partial checkouts and another engineer or team works to keep everything integrated into regular builds. You don't need the full game locally to rig a model or paint a texture, and even some gameplay stuff can be tested in a graybox demo environment without the full game assets before being integrated.

reactordev 4mo ago

Has nothing to do with Perforce being the Oracle of VCS because it’s baked into the big 3? Riiiight.

jhatemyjob 4mo ago
It's not even baked into Google anymore.
- Arainach 4mo 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. https://graphite.com/blog/google-perforce-to-piper-migration https://graphite.com/blog/google-perforce-to-piper-migration
  - jhatemyjob 4mo ago
    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 4mo 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 4mo 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.

ultrahax 4mo ago

Can confirm, we have a team dedicated to the care and feeding of p4.

raincole 4mo 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. 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 4mo 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.
- fc417fc802 4mo ago
  > Now we can rewrite the history of the LFS repo on an as-needed basis. With the giant caveat that doing this effectively breaks the history of the parent project. TBF that's not really any different than rewriting history and later discovering that an old version of a lockfile no longer works but I still think it's worth mentioning.
  - Marsymars 4mo ago
    Yeah, I can't edit my first post, but should note that if you don't want to rewrite history of the submodule, it also at least lets you consistently do shallow clones of the submodule - various git-related CI/CD operations on the main repo won't work with shallow clones, so it's a pain if you have to pull in a million old versions of binary dependencies just to run gitversion. As far as rewriting the history of the submodule goes... that's really something we're okay with - for us, the alternative to the git submobdule was just an SMB share - indefinitely keeping old binary dependencies isn't something we want to do.

IshKebab 4mo 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 4mo 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.)
- IshKebab 4mo 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.

j1elo 4mo ago

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.

slowmovintarget 4mo 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.

throw0101c 4mo 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 4mo ago
Mercurial is a bit better, but not by much it had slightly better large file support historically but I wouldn't recommend it.

DonHopkins 4mo ago

Git LFS causes nothing but pain, suffering, and regret.

GabeIsko 4mo ago
I braced myself for this, and instead found that it worked surprisingly well for my uses. I only manage 4 gigs though.

Calgaryp 4mo 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.

bc1000003 4mo 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 4mo 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. 1: https://gitlab.com/groups/gitlab-org/-/work_items/15061 https://gitlab.com/groups/gitlab-org/-/work_items/15061
maccard 4mo ago
> Perforce does get the job done and it's reliable and stable. Well… perforce does get the job done, but it does need a lot of hand holding from an admin (and you need someone who knows p4 server if you’re using it). It’s also stable in the sense of “it has exactly the same feature set as it did 15 years ago, and branches (streams) are considered modern”.

MayeulC 4mo 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.

apatheticonion 4mo 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 4mo ago
There's `--filter=blob:none` and it allows to automatically fetch blobs when needed.
- apatheticonion 4mo 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).

woctordho 4mo 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.

StellarScience 4mo ago
10 months or so ago I believe HN posted "The future of Large Files in Git is Git" : https://tylercipriani.com/blog/2025/08/15/git-lfs/ https://tylercipriani.com/blog/2025/08/15/git-lfs/ So is it the future now?

left-struck 4mo ago

Can this be used for Solidworks models? PDM is so awful

throw2ih020 4mo ago
Yeah, engineering is another use case for Perforce, will be interesting to see if Epic pursues that market too. I know UE has some use in industries like architecture and professional simulators.

toobulkeh 4mo ago

Why do you need to lock anything? To prevent someone else from working on it? To prevent duplicative work? That sounds like a management/coordination issue. Not a VCS issue. So you have version A and version B. Why are 2 artists working on the same asset without coordination? Do they not use task tracking or project management? Even if that’s ignored, then one person’s work gets wasted. That happens all the time in text based dev too if it’s lacking coordination. Should coordination live in the VCS layer? That sounds like it creates more issues than prevents.

lentil_soup 4mo ago
Because it's not so cleanly cut. Editing a level might touch several files without you realising, you might move a mesh file which causes 100s of references to update across 100s of files. For example, you want several people collaborating on a level. Say a level designer, an artist, a lighting person, audio. Usually you split this into several files to allow for the collab but you're bound to hit moments where you need to edit across the board. The level designer moves an area which causes the light, audio, meshes to move. If you don't have a way of knowing someone else is working on those files you're going to step on a lot of toes. Whether this should live separately from source control is a fair question, but it's just a simple place for it as it's tied directly to the files. Also, the outcome of a mistake is quite high, it could mean a whole day or two (a week?) of wasted work because you didn't realise someone was also editing the same file.

tikotus 4mo ago

I like putting it like this: VCS can be centralized or decentralized, and it can version per file or per commit. For games you want centralized per file versioning, like Perforce. Git is decentralized per commit versioning.

maccard 4mo ago
I mostly agree. I think for games you want per commit versioning 95% of the time. You don’t _really want developers building with cherry picked old revisions etc, but you don’t want an artist to have to pull down the 8TB of new art content that was submitted in the last 48 hours to update a texture.. the only way to do that is per file versioning!
- tikotus 4mo ago
  Indeed. But luckily those who mostly want per commit versioning are coders, and they are technical enough to find a solution for this. Like perforce git interface.