Re: Git push over git protocol for corporate environment

[Michael Poole <mdpoole@troilus.org>]

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