[PATCH] When re-initializing, set shared permissions on all directories.

[PATCH] When re-initializing, set shared permissions on all directories.

[Jon Jensen]

Hi.

Below is a small patch to make git-init --shared change permissions not 
just of .git/refs/ but of the other directories too.

Also a documentation patch for git-init, though after reading discussion 
in the list archives from a few weeks ago, I realize people may not be 
interested in documentation that shows explicit UNIX commands that may not 
apply or could be considered pedantic. Let me know if there's a better way 
I can approach this.

Thanks,
Jon


--
From b2895649165d7e6c4bcbe6484d66c84ea7124bd9 Mon Sep 17 00:00:00 2001
From: Jon Jensen <jon@endpoint.com>
Date: Tue, 20 Nov 2007 20:01:14 -0700
Subject: [PATCH] When re-initializing, set shared permissions on all directories.

Before this patch, when re-initializing an existing repository e.g.
as --shared=group, only .git/refs/ was set chmod g+ws. Now the
other directories get that too.

This is probably only helpful when not much has been done with the
repository yet, since it doesn't include subdirectories and files,
so add an example to the documentation to point the way for people
to finish the job.
---
  Documentation/git-init.txt |   13 +++++++++++++
  builtin-init-db.c          |    8 +++++++-
  2 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 07484a4..c4a4757 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -101,6 +101,19 @@ $ git-add .     <2>
  <2> add all existing file to the index


+Adjust an existing git repository to work as if it had been created with git init --shared::
++
+----------------
+$ GIT_DIR=/path/to/my/.git git-init --shared  <1>
+$ chgrp -R mygroup /path/to/my/.git  <2>
+$ find /path/to/my/.git -type d -exec chmod g+ws {} \;  <3>
+----------------
++
+<1> adjust configuration for shared repository
+<2> correct group ownership of any existing directories and files; needed if group shared by users is different than the group ownership of repository files
+<3> make all directories set group ownership of newly created files correctly in the future
+
+
  Author
  ------
  Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 763fa55..d16efa5 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -24,7 +24,13 @@ static void safe_create_dir(const char *dir, int share)
  			exit(1);
  		}
  	}
-	else if (share && adjust_shared_perm(dir))
+
+    /*
+     * If the directory already existed, we may still need
+     * to adjust permissions if this is a reinitialization
+     * for a shared repository.
+     */
+	if (share && adjust_shared_perm(dir))
  		die("Could not make %s writable by group\n", dir);
  }

-- 
1.5.3.6.737.gb2895

Re: [PATCH] When re-initializing, set shared permissions on all directories.

[Junio C Hamano]

Jon Jensen <jon@endpoint.com> writes:

> Below is a small patch to make git-init --shared change permissions
> not just of .git/refs/ but of the other directories too.

Those existing calls to adjust_shared_perm() are not about
changing permissions for existing directories, but are meant to
change the ones we _create_ under the user's umask() during the
initialization.

As you said, your change does not go far enough and you have to
tell the users to run "chmod" (and "chgrp") anyway.  If we were
to update init-db, then it would need to do the recursive chmod
and chgrp itself.

However, the user need to do recursive chmod and chgrp to
correct earlier screwups and to adjust to the new reality anyway
(see below), and doing so using vanilla filesystem tools is
often easier.  It might be better to train them early how to do
so, instead of making git-init a specialized command that knows
how to run chmod and chgrp in $GIT_DIR, as one of the major
strength of git comes from the fact that its implementation is
transparent.  People who can read or write under $GIT_DIR can
access or build on the history --- it's just that simple.
Exposing users to the filesystem enhances that transparency.

Two reasons for correcting an initial screw-up, and two reasons
for adjusting the new reality are:

 (A) making a non-shared repository to a shared one; you need

     $ find .git -type d -print | xargs chmod g+rwxs
     $ find .git -type f -print | xargs chmod g+rX

 (B) the same as above but the repository is owned by your
     personal group, not project; you further need

     $ chgrp -R projectgroup .git

 (C) an already shared project repository is transferred to a
     new group; you need

     $ chgrp -R newprojectgroup .git

 (D) a shared repository is turned back to a private one; you
     may need (if you are paranoid and do not want them to be
     read):

     $ find .git -type d -print | xargs chmod go=
     $ find .git -type f -print | xargs chmod go=

    or (if you only want to refuse writing)

     $ find .git -type d -print | xargs chmod g-w
     $ find .git -type f -print | xargs chmod g-w

Of course the above assumes that your umask is at most 077 (iow,
you did not forbid any access to yourself).

So I'd suggest us to do this in three steps:

 Step #1. Documentation.

   (1) How to transform a personal, non-shared project to a shared
       one;

   (2) How to transfer a shared project from one group to another;

   (3) How to transform a shared project to a non-shared,
       private one (two variants);

   I think your documentation patch is a good start, but notice
   the differences from the above (A)-(D).

 Step #2. Teach "git-init --shared" to do (1),

 Step #3. Discuss if we want to teach the "re-initialization"
          mode of git-init to do (2) and (3) as well, and if so,
          design and code it.  We'd need new options to name the
          desired group and such so it would involve an
          interface change.

Personally, I suspect that we do not need to go any further than
Step #1 above, but people who like "magic" may disagree.  Don't
take my suspicion as a rejection.