Subject: Re: Behavior of core.sharedRepository on non-bare Repositories

From: Junio C Hamano <[email-masked]>
Date: Mon, 17 Jan 2022 15:12:10 -0800

Junio C Hamano <[email-masked]> writes:

> But allowing write access to the same repository from multiple
> working trees were considered worth supporting.  More importantly,
> the repository data access by git is not uncontrolled---there are
> protections with lockfiles to avoid overwriting others' changes.

IOW, the expected set-up is for a repository (bare or non-bare) is
marked as shared, owned by the group, and each user who wants to
work locally on that project sharing the repository would belong to
the group.  Each user has a worktree added to the repository (via
"git worktree add") and it is OK (and may even be encouraged) to
have their umask stricter than 022 to prevent other users in the
same group from mucking with the worktree files.  Since Git sets
the permission bits of these shared repository files to allow access
by group members, looser than what umask(1) gives as needed, users
can share the repository contents without giving too loose an access
to the worktree files.