Re: git gc changes ownerships of files linux

[Junio C Hamano <gitster@pobox.com>]

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".