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

        . git-sh-setup-script
        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"

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.

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

Reply via email to