Comment by throw2ih020
9 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.
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.
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.
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?
28 replies →
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.
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.
Banks absolutely love security by obscurity. No clue why.
3 replies →
Can confirm split repos is an excellent solution for protecting IP.
That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering.
Does Gitlab do better with this?
I guess it's because git wasn't developed as enterprise software.
1 reply →
> 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.
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.
git repos viewed through gitlab's slow Ruby monolith are still git repos, so it doesn't make any difference.
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.
No.
The maximum granularity is also 'per repo'.
Try gitolite?
https://gitolite.com/gitolite/index.html
It has fine-grained permissions but works with regular git clients.
Does it actually restrict read access to specific directories? Unless I missed it, I didn't see anything in the docs about that.
2 replies →
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.
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.
8 replies →
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.
3 replies →
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.
Turn it into a business
The way I usually solve this is by using git submodules.
Oh man, I've been laughing at this for 37 minutes straight now.
2 replies →
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.
2 replies →
> 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
Does `--no-verify` override the restriction via hooks, or are there some kind of server-side hooks that can be used?
1 reply →
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.
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.
People don't use git crypt nearly enough unfortunately.
1 reply →
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.
2 replies →
Git submodules + SSH keys is another (somewhat "homebrew") solution to this.
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.
I think that’s the point of the OP. Git is great at certain things but is not a one size fits all.
>Thats not what its for.
This is a weak argument you could use for any missing feature.
1 reply →
Obviously, and that's why tools like perforce and lore exist. What's your point?
1 reply →
My hackernews is terrible at reading, nobody said any of that shit
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.
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.
> 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.
I think you can delete the history but it’s hard (more than three steps), at least that was my conclusion from the e blogpost below
https://janetgilbert.net/staging/2026/04/27/dealing-with-old...
> that there is no way to delete very old history
That's one of the features of Git LFS is separately managed storage and lifetime.
You are correct that GitHub does not offer that feature.
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.
LFS is not installed by default alongside git, it's a separate package in most systems
P4 is more "industry standard" than "state of the art"... But it does handle large files and partial checkouts without feeling bolted on.
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.
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
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.
One of those ideas that sounds clever in theory but in reality doesn’t work very well
Also... it's kind of weird taking a decentralized system and recentralizing it.
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.
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
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.
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.
Yeah that seems like an awful solution. This is exactly why we use perforce and just shove _everything_ in it.
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
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
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).
Can you name five?
1 reply →
[flagged]
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.
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.
Solving merge conflicts on text-based files is infinitely easier than binary-based. It's not a useful comparison.
1 reply →
> 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.
1 reply →
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.
Has nothing to do with Perforce being the Oracle of VCS because it’s baked into the big 3? Riiiight.
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).
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.
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
2 replies →
It's not even baked into Google anymore.
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
4 replies →
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 predates most of the VCSes we consider "modern"
p4 also significantly predates VCSes we consider obsolete. p4 is almost a decade older than SVN.
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.
> 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.
I've had the misfortune of scripting an UE build with perfoce as the VCS, it truly is abysmal.
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.
> 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 ?
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.
Can confirm, we have a team dedicated to the care and feeding of p4.
> 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)?
Mercurial is a bit better, but not by much it had slightly better large file support historically but I wouldn't recommend it.
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.
Git LFS causes nothing but pain, suffering, and regret.
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.
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.
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.
15 years ago, both Google and Microsoft were on perforce. (The latter through a fork with a different name.)
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`.
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.
> 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.
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.)
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.
1 reply →
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.
1 reply →
[flagged]
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.
There are some projects:
* https://github.com/jj-vcs/jj
* https://nest.pijul.com/pijul/pijul
Also some older but still kicking alternatives:
* https://darcs.net/
* https://mercurial-scm.org/
With respect, were you around to use any of its predecessors?
I was. I thought, and still think, that svn was much more pleasant to use than git. Alas, I am in the minority.
5 replies →
Yes. Some software is just really bad.
turns out version control is hard
We did, mercurial just didn't win.
[dead]
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.
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 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.
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.
Jonathan Blow found it convenient to represent all assets in a large number of text files, to enable merging. For instance he'd have one text file per entity on a map. The game and editor could read either this or the compiled binary version.
Jonathan Blow works with extremely small team sizes relative to the big studios. When you only have a couple people working on a project you don’t need all of the same coordination features.
He and Casey Muratory make a lot of cool instructive content, but their condescending attitude towards the industry always made me thing "Huh, must be really nice working alone and making all the decisions yourself."
22 replies →
He's also the sort of person who I suspect works in a very idiosyncratic way, which is great for him and his mind but probably not everyone else. (This is not a criticism.)
That's fine for database-like meta-data (e.g. game entity properties), but not for images, videos or audio files. Just writing those as hex dumps into text files doesn't make them any easier to merge.
You really can't merge binary data, such as textures, meshes, audio, etc. It doesn't matter if you base64 encode the data and stuff it in a text file: it's a jumble of data (assuming this is the implication of what Blow did).
He uses SVN and specifically has stated that Git isn't suitable for the work he does due to big binaries in source control.
How do you merge changes to a texture, mesh, audio file, etc?
Git LFS has file locking, and no VCS can provide you with the tools for diffing binary assets. I don't see any meaningful difference between Perforce, Diversion or Lore and git + LFS + file locking. Unless there's a meaningful performance impact for large projects (I only work on small / medium projects), the capabilities are the same. However, I get excellent git support for code in any editor, as opposed to Diversion or Lore which have none.
Git LFS for example does not support file chunking. So a single byte change on a large (100s of gigs) file means downloading the whole file again. Lore does chunking of binary files which means faster downloads and better de-dupping on the backend.
Permissions is another thing. Git permissions are done one a per repo basis.
https://epicgames.github.io/lore/explanation/system-design/#...
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.
I haven't made games for a long time so I can't speak for my experience, only my friends. From what I understand (1) Perforce has decent integrations with the game engine editors my friends work with, so editor support is no factor for them and (2) it has better delta support for the file types they work with - I believe Git LFS mostly uses a generic xdelta diff which is kind of mediocre at everything versus Perforce can understand different file types and be extended to support custom types.
I guess you never worked with anything but git? The devil is in the details, and those details generally suck more in git (or generally: distributed version control systems) than in traditional centralized VCS's.
Also git-lfs is a crutch that breaks more often than it works :/
(I agree though that for small game projects, git is mostly 'good enough', even without lfs).
Git LFS breaks so often that it can't be seen as a serious professional tool tbh. I've had nothing but trouble with it. If it wants to be serious it needs to be built into Git, not added as some after thought.
> 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.
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.
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
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.