It depends on the VCS you use. I don't know any ways to manage read permissions, such as allowing a person to checkout one directory but not another, though you can do that per branch on git.

But there are many ways to manage write permissions - limit the directories to which engineers are allowed to push code. E.g. if you use Git, this can be done with Gitolite, which is a popular hosting server.

Gitolite has very flexible hooks support, especially with so-called "Virtual Refs" (or VREFs)[1]. It is out of the box and has support to manage write permissions per write path [2]. You can go even further and use your own custom binary for VREF to "decide" if a user is allowed to push certain changes. One possible option - read incoming changed files, read metainformation from the repository itself (e.g., CODEOWNERS file at the root of the repo), and decide if push should be accepted. GitHub has CODEOWNERS [3], which behaves similarly.

[1]: https://gitolite.com/gitolite/cookbook.html#vrefs [2]: https://gitolite.com/gitolite/vref.html#quick-introexample [3]: https://docs.github.com/en/repositories/managing-your-reposi...

It's mostly about read/access permissions. I'd like to stay away from any type of git hook tbh

Gerrit can do some of that.

You can set permissions on writes.

Optional, per-directory OWNERS files are common, and most VCS frontends (Github, Bitbucket, etc.) can be configured to prevent merges without approval from the owning team(s) or DRI(s).

PRs that intersect multiple teams' ownership would require handoff of everyone impacted. So a team updating the company-wide "requests library" (or an equivalent change), with a wide blast radius, would be notifying everyone impacted and getting their buy-in.

Thats sounds like the type of workflow you would use with gerrit. It's technically multiple repos, but still implements the idea of an atomic build across all repos.

Then you configure ACLs for every repo or branch.

That depends on your VCS. Some systems don't even allow you to "clone" anything. And yes, some of them enforce all kinds of ACLs.

> there a way to set permissions on certain directories / force partial clones.

No. And that's one reason small startups should separate frontend code into a separate monorepo.

If you would like to hire a contractor for SEO/web developer then give them access to frontend code. Keep the backend code segmented out.

This is exactly my point. I like git, I like monorepos, but I do care about control over access and history.

I use git mainly because everybody knows it, tooling is there, etc.

With git you can accomplish this with submodules (eg. Main private repo with public submodules, or vice versa), but they are unpopular because they are fairly tedious to use.