Is git-am expected to honor core.sharedRepository?

Hi, everyone

I'm not very familiar with this setting, but to my understanding it should only affect files in $GIT_DIR not $GIT_WORK_TREE, is that correct? Nevertheless, apply and am (which uses apply) end up adjusting the permissions of created directories based on the setting. To give an example:

We first commit the directory 'd': $ mkdir d $ touch d/f $ git add d $ 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: $ git format-patch -1 $ git reset --hard HEAD~ $ git config core.sharedRepository 0700 $ git am *.patch

The setting was honored by am: $ ls -l drwx--S--- 2 matheus matheus 60 dez 1 11:30 d

And if we delete 'd' and check it out again, the setting is ignored: $ rm -rf d $ git checkout d $ ls -l drwxr-xr-x 2 matheus matheus 60 dez 1 11:31 d

Is this expected?

If not, the place to be changed is probably the safe_create_leading_directories() call in apply.c. This function internally calls adjust_shared_perm() to modify the permissions according to core.sharedRepository, so we could probably pass a flag to skip this step. But this function has at least 15 callers, so should we introduce a wrapper for the non-shared case, instead?

(For some background, I stumbled across this while considering using safe_create_leading_directories() for a parallel-checkout patch. But then I noticed it adjusts the directories' permissions based on the setting and I was worried whether it could be user for checkout.)

Thanks, Matheus