Re: git /objects directory created 755 by default?
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:15
Johannes Schindelin [off-list ref] writes:
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.
That somebody has to be somebody who owns .git directory not just a group member, so that is not a serious objection either, but you need to realize I was joking with 0777 -- a saner default would obviously be 0775. Otherwise you would not be able to server it from gitweb safely -- http server is typically not a group member.
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?
I am afraid that is going backwards. Nobody *needs* core.umask either, but we are still talking about this. That is because you wanted to make things easier for people, and I agree with you that it would be nicer if we did not require people set umask to sane values suitable for group work themselves, but somehow we did that automatically for them. The longer I think about it, however, the more I feel this is a lost cause. Earlier, I suggested git-shell one-liner, only because I thought git-shell users (or administrators that support git-shell users) may not have any way to set the umask to sane values themselves, but I think that should also be doable by telling sshd what the initial umask of the users should be. And that was where this umask discussion was started, but I think not touching umask at all is the right direction. Your core.umask would make sure the .git/objects/ directory would be suitable for other members, but git is not the only tool the people would use in the working tree. To work well with an editor that does not overwrite an existing file but does creat/rename upon saving would require you to have a sane umask if the user adopts your "shared working tree writable by all members" workflow. Running "make" in the working tree would leave object files, worse yet in a temporary build directory make created, with permission bits masked with your umask, making it imposible to run "make clean" for other members. Regardless of where and how people come from to work in the working tree, they need to set umask appropriately anyway. The only possible issue is one umask might not be sufficient, but unfortunately you can have only one umask at a time. The example of "receiption branches" is not a shared repository for me in the strict sense, but allows for you to push into. I cannot work with umask 022 in such a repository even if I wanted to have files in the working tree honor tighter umask. To deal also with such cases, not mucking with umask but solving the problem in a more direct way may make more sense -- namely we should be able to say "such and such things under .git/ in this repository must be ug+rw regardless of user's umask".