Re: [RFC][PATCH] Rewriting revs in place in push target repository

On Sat, 13 Aug 2005, Junio C Hamano wrote:

Petr Baudis [off-list ref] writes: 

quoted

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