threads / discuss / 22478

working directory umask

Subject: working directory umask

## tl;dr

2 messages between Feb 2, 2010 and Feb 2, 2010.

replies: 1people: 2as markdown or json

D Herring· Feb 2, 2010, 06:30 UTC · lore

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· Feb 2, 2010, 06:43 UTC · re: D Herring · lore

Re: working directory umask

D Herring <dherring@tentpost.com> 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.