summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: af6e277)
raw | patch | inline | side by side (parent: af6e277)
author | Junio C Hamano <junkio@cox.net> | |
Fri, 23 Dec 2005 23:27:18 +0000 (15:27 -0800) | ||
committer | Junio 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 | patch | blob | history |
index 3a5c56e24edfe7a970e6dcd346f8c0a346cdbfd8..edd91cbbe42bec1ee406dd95d82832575d89d3a6 100644 (file)
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)