Deny READ of specific repository branches with gitolite

What I'm trying to achieve is the following: coworkers are in group @coworkers, clients are in group @clients.

The Git repo shall be available to read and write for everyone, but there shall be special branches. i.e. I create a new branch "intern" and @coworkers shall have RW+ acces, but clients should NOT be able to R or W.

I thought i can achieve that by

repo myrepo
    -    intern    = @clients
    RW+            = @clients @coworkers

But this does not work.

According to a discussion with the author of gitolite, read access restriction is not possible for branches:

Gitolite's per-branch stuff works only for write access. It doesn't work for read access because git itself does not support making that distinction.

It is now possible to restrict read access to gitolite branches with the latest version of gitolite v3.x using the partial-copy feature of gitolite

1. Be sure to use the latest gitolite version
2. uncomment the partial-copy line in the ENABLE section of the ~/.gitolite.rc file
3. set $GIT_CONFIG_KEYS = '.*' in the ~/.gitolite.rc file
4. Use the partial-copy option to have another repository which is a copy of your original repository but without some branches.

Example: if you want the client to only have access to the deploy branch

repo    my-repo
    RW+     =   @coworkers

repo    my-repo-deploy
    RW  deploy  =   @clients
    -           =   @clients

    -   VREF/partial-copy           =   @all
    config gitolite.partialCopyOf   =   my-repo

if git complain that it cannot delete the master branch you can use this command on the server:

sudo git config --system receive.denyDeleteCurrent warn
sudo git config --global receive.denyDeleteCurrent warn

The clients can now clone the deploy branch of the my-repo-deploy repository with a command like this:

git clone -b deploy git@your-server:my-repo-deploy

I'm not a gitolite expert, but I think the rules are processed in order. Have you tried simply reversing the last two lines? That is, grant permission to @clients and @coworkers first, and then secondly deny access to intern by @clients.