On Sat, 13 Aug 2005, Junio C Hamano wrote:
>
> Petr Baudis <[EMAIL PROTECTED]> writes:
> > Rewrite refs in place in receive-pack & friends
> >
> > When updating a ref, it would write a new file with the new ref and
> > then rename it, overwriting the original file. The problem is that
> > this destroys permissions and ownership of the original file, which is
> > troublesome especially in multiuser environment, like the one I live in.
>
> Hmph. If a repo is _really_ used multiuser then you should not
> have to care about ownership.
I think Pasky's usage is that different heads are owned by different
groups and/or users, and he wants to use the filesystem permissions to
determine who gets to update which branch. Which is reasonable in a way.
On the other hand, I don't think filesystem permissions are really very
useful. I think it's more appropriate to use triggers to say something
like "only allow people in the 'xyz' group to write to this head".
Obviously, triggers aren't about _security_ - somebody who has write
permissions to the tree can always screw up others. But triggers are fine
for things like branch ownership, where you trust your users, but you just
want to avoid mistakes.
So a trigger might be something like
#!/bin/sh
. git-sh-setup-script
branch="$1"
old="$2"
new="$3"
if [ -e $GIT_DIR/permissions/$branch ]; then
id=$(id -un)
grep -q "^$id$" $GIT_DIR/permissions/$branch ||
die "You're not allowed to write to $branch"
fi
true
and that would allow you to list all users that are allowed to write to
the branch in $GIT_DIR/permissions/<branchname>.
Totally untested, of course. But the concept should work.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
