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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
