Wincent Colaiuta ha scritto: > > using the administration tools designed for managing access, just like > every other SCM (and every server, and every piece of software which can > be accessed by many on a multi-user system). > I don't agree in general: in SCMs and other multi-user softwares, the access control configuration can be safely postponed just because it's in their standard usage pattern that the access should be conditioned by a daemon to be configured later. It's not the case of git, just because git is very tied to *nix permissions. But as it is now, it could seems that it's good to put committers in the (for example) git group, just because you have a git administrative account git:git . This is caused, imo, by the fact that the flow of creating a shared repository for a specific work/project group with git-init run by an administrative user (as it should be) is something like this: - Do it wrong; - Fix it immediately. I don't like the "Do it wrong" part. I'm trying to produce a sane and transparent patch to implement the selectable group just in case of repository first initialization. Why do I care so much of first time users? Dunno, but I think it's important. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
