Re: git gc changes ownerships of files linux

> Torsten Bögershausen <tboegi@web.de> 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".
>
>