From: Johannes Schindelin Date: Thu, 22 Dec 2005 19:28:45 GMT Subject: Re: git /objects directory created 755 by default? Message-ID: In-Reply-To: <7vwthxlzai.fsf@assigned-by-dhcp.cox.net> Hi, On Thu, 22 Dec 2005, Junio C Hamano wrote: > When we talk about "CVS-style shared repository", we know what > it is -- there is no such thing as "*the* working tree > associated with the repository" and there is no room for > disagreement. This is what I mean by shared repository. > I could give each of the gitsters I trust an git-shell account > on my private machine and prepare refs/heads/rcpt/js branch for > you and refs/heads/rcpt/ae for Andreas to push into (I would use > Carl's per branch push policy to make sure those "receipt > branches" are the only ones you guys can push into if I did so). > > Then instead of sending "I now have this public repository and > have goodies for git improvement; please pull" e-mail to me, you > could push into your branch. I will keep working on master (and > my own topic branches), with whatever branch checked out in the > working tree, and merge from those rcpt branches at my leisure. > You guys are not allowed to touch my working tree, though. This has some merit, for example, when some of the contributors have no public repository. > In such a scenario, there is no reason to forbid me from > applying umask 022 to my working tree files, even though making > sure that fan-out directories of .git/objects/ *I* lazily create > can be writable by you is essential. > > I have a feeling that it might be good enough to modify > safe_create_leading_directories() to chmod(0777) after creating > a new directory under .git/ (or limit it to .git/objects/). The > repository administrator can restrict things further by chmod > 0770 .git/ as needed. And then somebody comes along and allows world access by chmod(0775) and does not realize that *everybody* can delete packs, objects and what-nots in GIT_DIR. Given the complexity we are talking about, and the needs which are not at all that complicated, why not just go with core.umask until somebody *needs* core.repositoryumask? Ciao, Dscho