I believe there may be a bug when initializing a new repository relating
to the directory permissions when the --shared=group option is used and
the repository is within a sub-directory.
The following will create the "test.git" directory with 2775 permissions
(which is as expected):
$ ls -ld test.git
ls: cannot access test.git: No such file or directory
$ git init --bare --shared=group test.git
Initialized empty shared Git repository in /tmp/test.git/
$ ls -ld test.git
drwxrwsr-x 7 pete users 4096 2012-11-14 11:15 test.git
This following will also create the "test.git" directory with 2775
permissions, BUT the "subdir" directory ends up with 755 permissions:
$ ls -ld subdir
ls: cannot access subdir: No such file or directory
$ git init --bare --shared=group subdir/test.git
Initialized empty shared Git repository in /tmp/subdir/test.git/
$ ls -ld subdir subdir/test.git
drwxr-xr-x 3 pete users 4096 2012-11-14 11:16 subdir
drwxrwsr-x 7 pete users 4096 2012-11-14 11:16 subdir/test.git
Assuming the "subdir" directory doesn't already exist and is created by
the "git init" command AND the --shared=group option is used, then
shouldn't the "subdir" directory also have 2775 permissions?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html