We make extensive use of unix permissions and core.sharedRepository -- 
multiple developers push to the same repo.

I have often wondered why core.sharedRepository is needed at all as a 
separate configuration?

It looks like it might be easier (and less confusing to users) to derive 
this attribute from the top-level .git directory?

For many years in our organisation we have been using the scripts below to 
make it easier for users to configure a repository -- a one-time 

Is there a reason why Git doesn't just follow (and echo) the top-level 

Many thanks


# Propagate permissions of the top-level directory through a repository,
# and configure it for use.

if [ "$1" = "--help" ]; then
        echo "Usage: $0 <bare_git_repo>.git"
        echo "Fix permissions on a Git repository, based on the permissions"
        echo "at the top level directory."
        exit 0

if [ -z "$1" ]; then
        echo "Repository argument is mandatory (see --help); aborting."
        exit 1


if [ ! -d "$REPO/objects" -o ! -f "$REPO/config" -o ! -f "$REPO/HEAD" ]; then
        echo "$REPO does not look like a bare Git repository; aborting."
        exit 1

# Fix ownership
chown -cR --reference="$REPO" "$REPO"/*

# Fix all the directory permissions after ownership (setting ownership
# removes setgid bit)
find "$REPO" -type d | xargs chmod -c --reference="$REPO"

# Fix files
find "$REPO" -type f | xargs chmod --reference="$REPO"
find "$REPO" -type f | xargs chmod a-sx

# Tidy up; permissions on object files are always 444
find "$REPO/objects" -type f | xargs chmod 0444

# Configure the repository to remove the need for further fixes
# by basing core.SharedRepository on the top level permissions
PERM=0`stat -c '%a' "$REPO"`
MODE=`printf %04o $(($PERM&0666))` # bash required
if [ "$MODE" = "0660" ]; then
elif [ "$MODE" = "0666" ]; then
git --git-dir "$REPO" repo-config core.sharedRepository "$MODE"
chmod --reference="$REPO" "$REPO/config"
chmod a-sx "$REPO/config"
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to