We're in the process of migrating a moderately-sized project from an old SCMS (CMVC) to Git/Gerrit. For external auditing purposes, we've implemented strict access controls within CMVC by defining 18 "components" and then creating ACLs for each of those components. Thus, the project exists as a large source tree (with a number of subdirectories, etc) in CMVC but a given developer might only have commit access for one particular subtree.
[note that our 'components' aren't independent, standalone apps or jars or libraries...they're just code subtrees that have specific ACLs needed to satisfy external code audits]
It's not clear to me how to achieve the same level of access control within Gerrit unless I convert each CMVC component into a separate Git project/repository with its own defined set of access groups.
The prospect of creating 18 separate projects is worrisome...
a) because of the risk of components getting out-of-sync (remember, our components aren't standalone apps or libs), and,
b) the number of Gerrit-mandated code reviews that will be required for committed changes that span components
Also, the thought of how our continuous integration stuff would identify and undo errant commits involving multiple repositories causes the hair on the back of my neck to stand up.
Is there a better way to achieve a fine-grained access control with Gerrit?
A crucial problem here is that Git itself doesn't really have any mechanism for operating only on particular directories in a repository: it's pretty much all-or-nothing. A particular commit can span multiple directories and there is no way to retrieve (or store) a "partial" commit.
You can implement filters that will reject commits that attempt to modify certain subtrees, but there's nothing you can do to limit pull access to these subtrees.
Access control in Git is typically implemented per-repository and per-branch.
If you need the sort of granular access control you have described and splitting the project into multiple repositories isn't an option, you probably need to investigate an alternative to Git for version control.