On Mon, May 16, 2011 at 6:52 PM, Martin L Resnick <mresnick@xxxxxxx> wrote: > Thanks for the reply. > > But gitolite would only work to deny reads on a repository or ref basis > not a pathname level. I notice the original question has been answered, so this email is just for the record. Gitolite does not do any access control on *read* access (fetch, clone). It can only do that on *write*s (push). Gerrit does that because they've reimplemented git itself and have coded that into their git engine somehow. I believe they had to implement a callback from jgit to gerrit for the fetch, and deal with evil clients that might try to read an object by pushing a supposed change on top of a SHA that they know but don't actually have. (Or something like that; I'm not real clear on this...). regards sitaram PS: Gitolite does have unreleased code to do this but it's a hack with several limitations. Gitolite makes a temp "clone -l", deletes all refs from it that the user has no access to, then redirects the git-upload-pack to that repo instead ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html