Re: Is git-am expected to honor core.sharedRepository?

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 1, 2020, 17:58 UTC
Message-ID: <xmqqpn3tqugm.fsf@gitster.c.googlers.com>
In-Reply-To: <CAHd-oW4yHSTYr0Gwn60tu2c7VY=PJbSbg23Z5Bd_11Do-+juGA@mail.gmail.com>

Matheus Tavares Bernardino <matheus.bernardino@usp.br> writes:

> If not, the place to be changed is probably the
> safe_create_leading_directories() call in apply.c.

https://lore.kernel.org/git/xmqqziglaxj4.fsf@gitster.mtv.corp.google.com/

Calling adjust_shared_perm() on a path outside .git/ is a potential bug, as you found out, and definitely a bug if used on working tree files. We may want to share with only selected users in a group the contents of the repository (e.g. allow local cloning from us), while allowing daemon-ish tools to scan what is in the working tree files without letting them touch what is in the repository, for example; adjust_shared_perm() is meant for .git/ repository files and tightening working tree files' permissions using it would break such arrangement.

I think bugreport uses scld, but it may be used to drop cruft inside the working tree, but the files created are *not* to be "git add"ed, so the use case does not count as "if used on working tree files".

Show 8 quoted lines

> $ git commit -m d
> $ ls -l
> drwxr-xr-x 2 matheus matheus 60 dez  1 11:29 d
> ...
> Then we create a patch and use am to apply it:
> The setting was honored by am:
> $ ls -l
> drwx--S--- 2 matheus matheus 60 dez  1 11:30 d

Having said that, I know it can be argued both ways. If we want to protect .git/ contents in a certain way, it may be worth protecting the files in the working tree in the same way as well. But at least that is not the current rule is (even though as you found out we do have bugs).

Thanks.