From b74ed497350844c3c9fc77c68de3843392086e9b Mon Sep 17 00:00:00 2001 From: Junio C Hamano Date: Fri, 23 Dec 2005 15:27:18 -0800 Subject: Tutorial: mention shared repository management. Signed-off-by: Junio C Hamano --- Documentation/tutorial.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt index 3a5c56e24..edd91cbbe 100644 --- a/Documentation/tutorial.txt +++ b/Documentation/tutorial.txt @@ -1695,6 +1695,24 @@ You still need to create UNIX user accounts for each developer, and put them in the same group. Make sure that the repository shared among these developers is writable by that group. +. Initializing the shared repository with `git-init-db --shared` +helps somewhat. + +. Run the following in the shared repository: ++ +------------ +$ chgrp -R $group repo.git +$ find repo.git -type d -print | xargs chmod ug+rwx,g+s +$ GIT_DIR=repo.git git repo-config core.sharedrepository true +------------ + +The above measures make sure that directories lazily created in +`$GIT_DIR` are writable by group members. You, as the +repository administrator, are still responsible to make sure +your developers belong to that shared repository group and set +their umask to a value no stricter than 027 (i.e. at least allow +reading and searching by group members). + You can implement finer grained branch policies using update hooks. There is a document ("control access to branches") in Documentation/howto by Carl Baldwin and JC outlining how to (1) -- cgit v1.2.1