I persuaded my employer to test Git -- with good results so far. But we 
have a problem with file permissions.

We use the setuid bit on much of our central file hierarchy to ensure that 
anyone in a certain unix group of trusted users can push.

I noticed that the .git/objects directory was losing this setuid bit.

This creates problems later, when subdirectories of .git/objects are 
created by one user, and another user does a checkin which requires write 
to that subdirectory:

drwxrwx--- 2 mhills trust 51 Apr 18 09:39 eb
drwxrwx--- 2 mhills user   6 Apr 18 09:40 f4
drwxrwx--- 2 mhills trust  6 Apr 18 09:39 info
drwxrwx--- 2 mhills trust  6 Apr 18 09:39 pack

The offending operation is a cpio-based file copy in git-clone.sh. I 
updated to the latest Git source and cpio, with the same issue.

I got some kind of working behaviour with the diff below, which stops cpio 
'fixing' the file permissions (only on the directories). But it seems the 
underlying cause is cpio trying to copy file permissions which it would be 
better off not doing in this case (and which there isn't a flag to 
disable).

Is this a known problem? How can we fix this properly?

Mark


diff --git a/git-clone.sh b/git-clone.sh
index 2636159..3b8280b 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -333,7 +333,7 @@ yes)
                         fi
                 fi &&
                 cd "$repo" &&
-               find objects -depth -print | cpio $cpio_quiet_flag -pumd$l "$GIT_DIR/" || \
+               find objects -depth ! -type d -print | cpio $cpio_quiet_flag -pumd$l "$GIT_DIR/" || \
                         exit 1
         fi
         git-ls-remote "$repo" >"$GIT_DIR/CLONE_HEAD" || exit 1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html