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

[Junio C Hamano <gitster@pobox.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".

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