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

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

"John A. Leuenhagen" <john@zlima12.com> writes:

> Based on the wording in the man page, I was under the impression that
> this would affect all files in any type of repository (bare or not), but
> it seems as though this is not the case. It affects bare repositories as
> one would expect, but it only affects the .git directory on non-bare
> repositories. The working tree is not affected by the option at all.

This behaviour, as far as I know, dates back way before "git
worktree add" was invented.  Such an arrangement to share the object
store and refs (i.e. contents of .git/) among multiple worktrees
were already available via contrib/workdir/ even back then.

The motivation behind the current design may be that sharing a
working tree between two people to allow overwriting each other's
change in an uncontrolled way with their editors is a total disaster
and nobody would consider doing such a nonsensical arrangement.  It
may be why we do not loosen the permission of working tree files
beyond what your umask does.

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.

If multiple people must write into the same repository and the same
working tree, the umask(1) command is your friend.  Add these users
to the same single group, have the repository and working tree files
owned by that group, and make sure these users have umask no
stricter than 007.