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.

The way I usually solve this is by using git submodules.

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.

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

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.

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

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

One of those ideas that sounds clever in theory but in reality doesn’t work very well

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.

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

It's not even baked into Google anymore.

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

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

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.

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

With respect, were you around to use any of its predecessors?

There are some projects:

* https://github.com/jj-vcs/jj

* https://nest.pijul.com/pijul/pijul

turns out version control is hard

We did, mercurial just didn't win.

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.

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.

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.

He uses SVN and specifically has stated that Git isn't suitable for the work he does due to big binaries in source control.

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

How do you merge changes to a texture, mesh, audio file, etc?

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.

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

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.

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.

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