git gc changes ownerships of files linux

> Hi team git
>
> Running 'git -C /srv/mssioncontrol/.git gc' on linux from a user which
> has access to another users files will occasionally change the
> ownership of the file 'packed-refs'. I believe git actually overwrites
> the file with a new one at the end af the gc command. But details
> about this is not writen in the help text. Could it be a bug?
>
> Use case: I'm using ansible to cleanup .git directories across
> multible servers and this issue is starting to cause problems.
>
> My solution is to make a variable containing the user and group id
> before running gc command and then reapply it afterwards:
> current_owner_uid_gid=$(stat -c "%u:%g" /srv/mssioncontrol/.git)
> git -C /srv/mssioncontrol/.git gc
> chown -R $current_owner_uid_gid "/srv/mssioncontrol/.git"
>
> Details:
> Debian GNU/Linux 12 (bookworm)
> git version 2.39.2

> Thanks for reporting this -
> I think that you have a working workaround ?
> 
> However, Git has a feature called "shared repository".
> You need to define a (unix) group that is shared between
> your user(s) and the ansible user.
> 
> The basic trick is to do
> git config core.sharedRepository true
> 
> (And then change the ownership of all files/directories to the new group)

> On 2024-02-11 at 15:14:55, Torsten Bögershausen wrote:
> > Thanks for reporting this -
> > I think that you have a working workaround ?
> >
> > However, Git has a feature called "shared repository".
> > You need to define a (unix) group that is shared between
> > your user(s) and the ansible user.
> >
> > The basic trick is to do
> > git config core.sharedRepository true
> >
> > (And then change the ownership of all files/directories to the new group)
>
> On Linux, you also should set each directory to be setgid.  That's
> because by default, Linux uses the user's current group ID as the group
> to create new directories.  However, you'll want the group to be
> inherited from the parent directory, which is the behaviour when the
> parent directory is setgid.
>
> This behaviour is the default on the BSDs, and no such configuration is
> required there.

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

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

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

>On 2024-02-11 at 16:43:33, Junio C Hamano wrote:
>> 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.
>
>I think it's relatively common to have shell hosts from which to log into production
>machines, or to have shared hosts for students at universities, and I do know that
>shared web hosting is still quite popular (because it tends to be very economical and
>low maintenance for the user).
>
>I don't know that shared repositories are really that common anymore, and I do
>usually recommend that people clone their own copies whenever possible, but I
>have seen posts on StackOverflow where people are in fact using a shared
>repository (possibly with multiple worktrees) on one system for various reasons.