It looks like you have a local resolution problem. There is nothing specific to Git for this problem. The hierarchy can contain anything, and these instructions will be exactly the same. By default, Git will perform the umask configuration described later (if it is not overridden by the core.sharedRepository configuration).
In your comments, you said that your user will update the contents of the hierarchy, and you will also have a web server that will read the contents of the hierarchy. I assume that the web server is running under a different user (this is usually the case (for example, Apache works as the httpd user)). In addition, I assume that this is acceptable if other users on the same computer can also read the contents of the hierarchy (the required permission scheme for this configuration is more complicated - it involves using a special group and ensuring that your files and directories this group as their "group owner".
Facts
- The hierarchy of concern is based on: / opt / lammp / htdocs / myProject
- The local user dan should be able to modify the contents of the hierarchy as he sees fit.
- The web server (possibly working as another user) should be able to read the contents of the hierarchy.
- Everything is fine if other users on the local computer can read the contents of the hierarchy.
Decision
- Dan will have the <owner> of the entire hierarchy. "The owner of the group does not matter.
- Give the user ( dan ) read, write and execute permissions for directories and at least read and write permissions for files (some files may be executable if (for example, they are scripts)).
- Give the group owner the same rights as the user, but without write permission.
- Grant all "other users the same rights as" user ", but without write permission.
Implementation
Initial setup
Make dan the owner of the entire hierarchy.
Grant everyone read permission (and also grant permission for all directories and all files that are already executed by someone, any write permissions are deleted). Also indicate permission dan .
This will separate the setuid / setgid / sticky bits and give the modes 755 and the modes of the executables and all other 644 files.
Current use
To make sure that new files are readable but not writable (by default) by other users (for example, a web server user), you must install your umask when working in this directory.
dan$ umask 022
This masks the "group" and other write permissions for new files and directories, but leaves only read and execute.
If you forgot to use this, and your umask is by default more restrictive (or less restrictive), you will need to re-run the chmod (non-sudo!) Command from the "Initial Setup" section. This will reset any rights that are too strict (or too loose).