Code

Tutorial: mention shared repository management.
authorJunio C Hamano <junkio@cox.net>
Fri, 23 Dec 2005 23:27:18 +0000 (15:27 -0800)
committerJunio C Hamano <junkio@cox.net>
Sat, 24 Dec 2005 08:21:11 +0000 (00:21 -0800)
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/tutorial.txt

index 3a5c56e24edfe7a970e6dcd346f8c0a346cdbfd8..edd91cbbe42bec1ee406dd95d82832575d89d3a6 100644 (file)
@@ -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)