* sharedRepository derived from file permissions
@ 2012-10-08 9:07 Mark Hills
2012-10-08 16:46 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hills @ 2012-10-08 9:07 UTC (permalink / raw)
To: git
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
operation.
Is there a reason why Git doesn't just follow (and echo) the top-level
permissions?
Many thanks
--
Mark
#!/bin/bash
#
# 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
fi
if [ -z "$1" ]; then
echo "Repository argument is mandatory (see --help); aborting."
exit 1
fi
REPO="$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
fi
# 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
MODE=group
elif [ "$MODE" = "0666" ]; then
MODE=all
fi
git --git-dir "$REPO" repo-config core.sharedRepository "$MODE"
chmod --reference="$REPO" "$REPO/config"
chmod a-sx "$REPO/config"
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sharedRepository derived from file permissions
2012-10-08 9:07 sharedRepository derived from file permissions Mark Hills
@ 2012-10-08 16:46 ` Junio C Hamano
2012-10-16 23:20 ` Mark Hills
0 siblings, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2012-10-08 16:46 UTC (permalink / raw)
To: Mark Hills; +Cc: git
Mark Hills <mark@pogo.org.uk> writes:
> 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?
Hrm, clever ;-)
> Is there a reason why Git doesn't just follow (and echo) the top-level
> permissions?
Other than "we did not trust that all the end users are capable of
doing the right 'chmod 2775 .git && chgrp project .git", with a
little bit of "we didn't think of that when we wrote the system", I
do not recall any.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sharedRepository derived from file permissions
2012-10-08 16:46 ` Junio C Hamano
@ 2012-10-16 23:20 ` Mark Hills
2012-10-17 7:46 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Mark Hills @ 2012-10-16 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Mon, 8 Oct 2012, Junio C Hamano wrote:
> Mark Hills <mark@pogo.org.uk> writes:
>
> > 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?
>
> Hrm, clever ;-)
>
> > Is there a reason why Git doesn't just follow (and echo) the top-level
> > permissions?
>
> Other than "we did not trust that all the end users are capable of
> doing the right 'chmod 2775 .git && chgrp project .git", with a
> little bit of "we didn't think of that when we wrote the system", I
> do not recall any.
Thanks. If I understand, you mean it might be worth a try to implement
this. For us it would certainly simplify, and reduce mistakes/confusion.
I've yet to look into the code, but I will try and do this. If you have
any hints or recommendations where to begin then that'd be good.
I think I did peek some years ago to find out that it was non-trivial, and
then came up with the script!
I wonder if there are any users who are granting permission to specific
branchs or tags or tag directories. I'm not sure if this is really a valid
use case, but there might need to be a way to ignore the top-level
attributes too for some special cases?
Thanks
--
Mark
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sharedRepository derived from file permissions
2012-10-16 23:20 ` Mark Hills
@ 2012-10-17 7:46 ` Junio C Hamano
2012-10-17 12:25 ` Mark Hills
0 siblings, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2012-10-17 7:46 UTC (permalink / raw)
To: Mark Hills; +Cc: git
Mark Hills <mark@pogo.org.uk> writes:
>> > It looks like it might be easier (and less confusing to users) to derive
>> > this attribute from the top-level .git directory?
>>
>> Hrm, clever ;-)
>>
>> > Is there a reason why Git doesn't just follow (and echo) the top-level
>> > permissions?
>>
>> Other than "we did not trust that all the end users are capable of
>> doing the right 'chmod 2775 .git && chgrp project .git", with a
>> little bit of "we didn't think of that when we wrote the system", I
>> do not recall any.
>
> Thanks. If I understand, you mean it might be worth a try to implement
> this.
Not really.
I still do not think that all the end users are capable of doing the
right 'chmod 2775 .git && chgrp project .git' themselves.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sharedRepository derived from file permissions
2012-10-17 7:46 ` Junio C Hamano
@ 2012-10-17 12:25 ` Mark Hills
0 siblings, 0 replies; 5+ messages in thread
From: Mark Hills @ 2012-10-17 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, 17 Oct 2012, Junio C Hamano wrote:
> Mark Hills <mark@pogo.org.uk> writes:
>
> >> > It looks like it might be easier (and less confusing to users) to derive
> >> > this attribute from the top-level .git directory?
> >>
> >> Hrm, clever ;-)
> >>
> >> > Is there a reason why Git doesn't just follow (and echo) the top-level
> >> > permissions?
> >>
> >> Other than "we did not trust that all the end users are capable of
> >> doing the right 'chmod 2775 .git && chgrp project .git", with a
> >> little bit of "we didn't think of that when we wrote the system", I
> >> do not recall any.
> >
> > Thanks. If I understand, you mean it might be worth a try to implement
> > this.
>
> Not really.
>
> I still do not think that all the end users are capable of doing the
> right 'chmod 2775 .git && chgrp project .git' themselves.
But with the current method, users still have to do this _and_ set
sharedRepository=.
It would make things hard or impossible if we assume that a user wanting
to share a repository does not understand file modes or groups.
--
Mark
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-10-17 12:25 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-08 9:07 sharedRepository derived from file permissions Mark Hills
2012-10-08 16:46 ` Junio C Hamano
2012-10-16 23:20 ` Mark Hills
2012-10-17 7:46 ` Junio C Hamano
2012-10-17 12:25 ` Mark Hills
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).