# working directory umask 2 messages from 2010-02-02 to 2010-02-02. Participants: D Herring, Junio C Hamano. Thread: https://gitlist.dev/t/22478 ## D Herring, 2010-02-02 06:30 Subject: working directory umask Message-ID: URL: https://gitlist.dev/e/hk8gq7%24o76%241%40ger.gmane.org ``` Hi all, So for one project at work, we have a (slow) server with a common build area. Standard practice has been to extract a tarball, configure, make, make install into a common area. I have started using git to replace the tarballs -- keep version info, make doesn't have to rebuild everything, auto-tag install sources, etc. One problem: Even though the working directory is g+swx and git was initialized with --shared=group or --shared=0660, the checked out source files still don't have group write permissions... Is there an option that I've overlooked? I can't seem to find anything that overrides umask in the working directory, only in the repo. Thanks, Daniel ``` ## Junio C Hamano, 2010-02-02 06:43 Subject: Re: working directory umask Message-ID: <7v8wbccf3x.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v8wbccf3x.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` D Herring writes: > One problem: Even though the working directory is g+swx and git was > initialized with --shared=group or --shared=0660, the checked out > source files still don't have group write permissions... It is working as designed. "shared" setting is about a shared central repository that is typically a bare repository, and currently it is implemented as such. You could argue that the behaviour for the work tree files is undefined and make the code act differently, though. In any case, it would be better to document this, and it might even make sense to issue a warning message when we detect the repository is used with a work tree (including the use of GIT_DIR and GIT_WORK_TREE environment variables to temporarily turn a bare repository with a work tree). Thanks for a report. ```