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

Junio C Hamano [off-list ref] 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.