{"thread":{"id":"22478","subject":"working directory umask","startedAt":"2010-02-02T06:30:32Z","lastAt":"2010-02-02T06:43:14Z","messageCount":2,"participants":["D Herring","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133323","messageId":"hk8gq7$o76$1@ger.gmane.org","threadId":"22478","inReplyTo":null,"subject":"working directory umask","fromName":"D Herring","fromEmail":"dherring@tentpost.com","sentAt":"2010-02-02T06:30:32Z","receivedAt":"2010-02-02T06:30:32Z","isPatch":false,"sender":{"key":"dherring@tentpost.com","avatar":null},"body":"Hi all,\n\nSo for one project at work, we have a (slow) server with a common \nbuild area.  Standard practice has been to extract a tarball, \nconfigure, make, make install into a common area.  I have started \nusing git to replace the tarballs -- keep version info, make doesn't \nhave to rebuild everything, auto-tag install sources, etc.\n\nOne problem:  Even though the working directory is g+swx and git was \ninitialized with --shared=group or --shared=0660, the checked out \nsource files still don't have group write permissions...\n\nIs there an option that I've overlooked?  I can't seem to find \nanything that overrides umask in the working directory, only in the repo.\n\nThanks,\nDaniel\n"},{"id":"133325","messageId":"7v8wbccf3x.fsf@alter.siamese.dyndns.org","threadId":"22478","inReplyTo":"hk8gq7$o76$1@ger.gmane.org","subject":"Re: working directory umask","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-02T06:43:14Z","receivedAt":"2010-02-02T06:43:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"D Herring <dherring@tentpost.com> writes:\n\n> One problem:  Even though the working directory is g+swx and git was\n> initialized with --shared=group or --shared=0660, the checked out\n> source files still don't have group write permissions...\n\nIt is working as designed. \"shared\" setting is about a shared central\nrepository that is typically a bare repository, and currently it is\nimplemented as such.\n\nYou could argue that the behaviour for the work tree files is undefined\nand make the code act differently, though.\n\nIn any case, it would be better to document this, and it might even make\nsense to issue a warning message when we detect the repository is used\nwith a work tree (including the use of GIT_DIR and GIT_WORK_TREE\nenvironment variables to temporarily turn a bare repository with a work\ntree).\n\nThanks for a report.\n"}]}