Marius Storm-Olsen <mstormo@xxxxxxxxx> wrote: > Shawn O. Pearce said the following on 01.10.2009 02:06: >> Michael Poole <mdpoole@xxxxxxxxxxx> wrote: >>> (Others have mentioned Gerrit. I use that at work, and my only >>> major wish is that it had per-branch rather than per-project >>> access controls. It is a vast improvement over the Subversion >>> system we had before.) >> >> You'll be happy to hear _everyone_ is demanding per-branch >> controls, I have to do it before the end of the year, maybe even >> before the end of the month... > > Ugh, any pointers on this one? Does this mean that you're planning to > add this sort of control in git itself, or just some way to facilitate > the setting of owner/group on individual ref files? What about packed > refs? I guess you don't know how Gerrit Code Review works, or missed that I was talking about Gerrit and not git. Gerrit behaves like Gitosis, it owns the repositories under its care, and (in general) nobody else is allowed to read or write to them except the Gerrit daemon process. That process is running JGit, not git.git, which means I have full control over the entire code that serves that repository. We already have write level control to branches in that JGit has per-ref hook support similar to what the update hook provides in git. It doesn't actually use the update hook, its an interface API the server implements and pushes down into the JGit library, and it has more control over the response issued to the client, but we get the same result. I'm just missing a UI that allows an administrator to configure that implementation's decision making on a per-ref basis. We don't yet have read level control to read branches, but this is fairly trivial to implement. I just need an interface API that can filter the refs before we advertise them to the client. Given my expand refs protocal extension that I started working on (but have not yet finished) I'd need something like that in JGit anyway just to implement the expand refs behavior. Teaching it to further filter refs by who can read what is then trivial. -- Shawn. -- 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