6 ms·
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 r
by 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 agoThat'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 agoGit 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 agoI feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.
- InitialLastName 4mo agoThat and a way to recursively commit/push (i.e. make a change within a submodule, commit in one step with the same message in the parent submodule). Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to: 1. Change the file 2. Commit within the submodule 3. Push the submodule 4. add the submodule change in the outer repo 5. commit in the outer repo 6. push the outer repo
- 1718627440 4mo agoYou can combine the push step. A submodule intentionally follows a different development/commit/version cycle, otherwise you are supposed to use a subtree.
- gritzko 4mo agoIn the Beagle SCM, I am doing my best to simplify that flow, but that is only doable because Beagle has multi-project repos. Still, there are some difficulties with submodule recursion. In the git model, difficult to imagine this working smoothly.
- a1o 4mo agogit submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.
- 1718627440 4mo agoYou can set submodule.recurse to true and then git commands operate as if you passed --recurse to them? It's just that most people don't actually want that, because a submodule is generally something you intentionally want to handle separate.
- 1718627440 4mo agoSubmodules ARE multiple repositories. This is not an either or.
- kccqzy 4mo agoI understand that. I am just arguing that making your build tool aware of multiple repos is enough; no need to use submodules in git and make your build tool pretend to operate on a single repo.
- stackghost 4mo agoI think everyone knows that this is a consequence of git's design. Nobody's disputing that. Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.
- PaulDavisThe1st 4mo agoAnd a few of them think that it is corporate structure and development models that are actually the problem. I'm just asking questions!
- stackghost 4mo agoI don't understand what you're trying to imply. If you're making the point that there are multiple confounding factors to just about any non-trivial problem, then I agree.
- PaulDavisThe1st 4mo agoNo, I'm making the point that the way in which git doesn't fit well into many corporate processes can be interpreted as more of a negative commentary on those processes than on git.
- deleted 4mo ago[deleted]
- rowanG077 4mo agoDoesn't git crypt solve this? You can have encrypted blobs in a repo that will be auto decrypted if you have a working key.
- giancarlostoro 4mo agoPeople don't use git crypt nearly enough unfortunately.
- freedomben 4mo agoAgreed. I use and love git crypt, but it doesn't get enough use. I think because it's easy to screw up gpg keys. Most of my uses (for one to three devs) have become symmetric keys shared out-of-band instead of using gpg keys because we've had lots of onboarding pain even from people who are quite competent. There are just a lot of sharp edges in gpg that you don't know when you don't know.
- zeratax 4mo agoi really want to use a similar tool that uses age instead of gpg, but the ones i've tried were all not as nice to use, or very undermaintained. but idk i havent checked in a while
- embedding-shape 4mo agoGit submodules + SSH keys is another (somewhat "homebrew") solution to this.
- everforward 4mo agoNot 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.
- MrDresden 4mo agoI once worked in a git repository that required those kinds of restrictions. This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it). Needing to figure out a way to protect those parts of the codebase it was decided in the end that the "easiest" way of doing this was to split the repository in half, with the actual artifact building taking place from the half that had the NDA code. The rest of the application (basically the whole application) was then used as a dependency by it. Still didn't quite solve the issue, but access to that repository was heavily controlled.
- SoftTalker 4mo agoStrikes 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?
- HWR_14 4mo agoThe code revealed the existence of Apple Pay, which had not been publicly confirmed.
- juancn 4mo agoIt's kinda like that, there could be a proprietary fraud detection heuristic in there that you don't want to get out.
- hk__2 4mo agoMaybe that’s some scoring to decide if you should be able to pay or not with some method.
- kurthr 4mo agoBecause it's Apple. They are huge, have scary lawyers, write scary contracts, and want to "delight the user" with features only when they announce them. They hate leaks, and demand separate teams for basically any/all development.
- PunchyHamster 4mo ago> That's not something that you can do in git: it's all or nothing. That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules
- jmaw 4mo agoDoes `--no-verify` override the restriction via hooks, or are there some kind of server-side hooks that can be used?
- PunchyHamster 4mo agono-verify cancels local hooks, remote hooks are unaffected. Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.
- jmaw 4mo agoInteresting. I'll have to do so reading into remote hooks!
- iveqy 4mo agoThe way I usually solve this is by using git submodules.
- bigbuppo 4mo agoOh man, I've been laughing at this for 37 minutes straight now.
- orthoxerox 4mo agoGit submodules are the regular expressions of version control.
- contingencies 4mo agoAFAIK 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.
- odo1242 4mo agoYou can set up submodules to not pull the other source repo by default tho
- Freedom2 4mo agoI ended up writing my own layer over git for permissions for a specific client a long time ago. It has a huge amount of useful features - sadly, I never took the idea further.
- stogot 4mo agoTurn it into a business
- Melatonic 4mo agoThat always seemed crazy to me about git. Permissions are a pretty basic enterprise offering. Does Gitlab do better with this?
- wtetzner 4mo agoI guess it's because git wasn't developed as enterprise software.
- yallpendantools 4mo agoThis. People forget a lot of Git's design philosophy harks back to the ethos of open source development. Enterprise features have made it in over the years but still mostly with the FOSS development workflow/model in mind. Also why the most enterprise-y of features (like LFS) are add-ons rather than core.
- GabeIsko 4mo agoIt's pretty sad in the indie gamedev world that handling and versioning binary data is considered an enterprise feature. I understand that git was explicitly designed for source code, but it would be nice to have any open system that handled versioning binary files well. This is pretty much the only reason I am going to try out lore at some point, although I am not super psyched at some of its implementation.
- m463 4mo agoMaybe you could go to linus and demand enterprise features and support. ;)
- oneplane 4mo agoHow 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.
- 4mo ago
- hhsecurity 4mo agoMy 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.
- francislavoie 4mo agoObviously, and that's why tools like perforce and lore exist. What's your point?
- Arainach 4mo agoPerforce predates Git by a decade (but your overall point is valid)
- fartcoin67 4mo ago[dead]
- cdmckay 4mo agoI think that’s the point of the OP. Git is great at certain things but is not a one size fits all.
- charcircuit 4mo ago>Thats not what its for. This is a weak argument you could use for any missing feature.
- 1718627440 4mo agoBut it's more like a fundamental design choice.
- __d 4mo agoTry gitolite? https://gitolite.com/gitolite/index.html https://gitolite.com/gitolite/index.html It has fine-grained permissions but works with regular git clients.
- LugosFergus 4mo agoDoes it actually restrict read access to specific directories? Unless I missed it, I didn't see anything in the docs about that.
- Grayskull 4mo ago"write access controlled at the branch/tag/file/directory level, including who can rewind, create, and delete branches/tags."[1] [1] https://gitolite.com/gitolite/overview.html#what-is-gitolite https://gitolite.com/gitolite/overview.html#what-is-gitolite
- LugosFergus 4mo agoI said read access. The point is that there’s restricted information that only some can access.
- anitil 4mo agoYour comment and the parent comment are fantastic. I'd never have thought of them because I've never worked in the field
- usrbinbash 4mo ago> Something else that git isn't good at: permissions. It doesn't have to be good at permissions. That's what DevOps platforms that integrate git are for.