Torsten Bögershausen <tboegi@xxxxxx> writes: > Briam, Hm, I wonder what this function (in path.c) does: > > int adjust_shared_perm(const char *path) > > According to my understanding, it was included into the Git codebase > to work around the missing "setgid" feature in Linux (and probably cygwin). No. "g+s on directory" is required and depended upon for getting the correct group ownership. We do not do anything to chown(2) a filesystem entry to force what group it is owned by there. What adjust_shared_perm() does is to counter what the screwed-up umask settings the user may have causes. If you are a member of a group and working in a directory owned by the group with other members, you want to make sure others in the group can access the files and the directories in the project. Their umask should be loosened to at least 027 and preferrably to 007 to give group members the same access as you do. Yet people do not loosen their umask when starting work in such a group owned directory that is supposed to be shared, as it would be extremely cumbersome to do [*]. These users end up creating files with overly tight permission bits, e.g. 0644 or 0700, and we go in with adjust_shared_perm() to fix these modes. You definitely must set up your initial directory with g+s if you are usihng the group-writable shared directory model (which I would actually be surprised to see in 2020---is a shared machine with more than one user-account still a thing???); adjust_shared_perm() will not help you there. [Footnote] * Unless, of course, you use some sort of "hook" in the shell to notice you switched to a certain directory and run command there---some people achieve this by aliasing their "cd", "pushd", and "popd".
