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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 17, 2022, 23:05 UTC
Message-ID: <xmqqo84at131.fsf@gitster.g>
In-Reply-To: <20220117223912.fwsydwpkwfbcdlcq@Zulu-1>

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

Show 5 quoted lines

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