On Sun, Feb 11, 2024 at 08:43:33AM -0800, Junio C Hamano wrote: > 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. > Oh - I learned something today and sorry for the noise. > > [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". > >
