Eugene Sajine writes: [snip] > My problem is that I need the simplest, easiest and fastest solution > from setup and maintenance point of view in a situation when we have a > huge CVS repo with hundreds of modules (projects) in it. My current > understanding is that we are going to pull out project by project from > CVS and create corresponding git repos. > So, this brings us to hundreds of git repos and over 200 hundred > committers. In this circumstances we don’t want to manage each repo > separately as well as we don’t want to manage each person write access > rights to each repo. > As I understand the best solution here is git protocol (one port only > on dedicated server and no security as we are in trusted network) with > read and write access configured for all repos on a dedicated server. > What do you think I should do? How to enable push over git protocol? How do you manage permissions now? How would you like to manage rights under the new system? I am a git amateur, but I would suggest using git+ssh (git over ssh) and use group or ACL permissions based on the SSH user account. The standard git-daemon does not provide authentication or authorization, so you would have to roll your own -- but git+ssh lets you leverage the operating system's built-in access controls. For example, some developers might belong to group A, and others developers belong to group B. With standard Unix permissions, you could grant global read but only group-A commit rights to any number of permissions (by appropriate use of git init --shared). I have not tried using POSIX ACLs to grant more complicated access rights for git repositories, but setting default ACL entries on the directory before running "git init" *should* give good results. (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.) Michael Poole -- 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