On Wed, Mar 06, 2024 at 08:36:25AM -0800, Junio C Hamano wrote: > Patrick Steinhardt <ps@xxxxxx> writes: > > >> Since the tempfile is now being created through the tempfile API, I > >> think the file mode can be set directly through `mks_tempfile_m()` > >> instead of creating the tempfile and then using chmod. Just something I > >> thought to mention. > > > > Unfortunately not. The problem is that `mks_tempfile_m()` will munge > > passed-in permissions via "core.sharedRepository", but we already pre > > calculated the target mode in `config.default_permissions`. Thus, the > > result would have wrong permissions if we used `mks_tempfile_m()`. > > I somehow found that default_permissions thing always disturbing. > > Even if we keep a separate mechanism for determining the file > permission (perhaps in order to give ourselves a better separation > as "an independent library" from the rest of Git), shouldn't the > permission setting that is computed by the mechanism and stored in > config.default_permissions be consistent with the permission the > rest of git computes based on core.sharedRepository? It is consistent. The problem is rather that `mks_tempfile_m()` takes a mode as input, but still ends up applying the umask to that mode. Thus, using that function without a subsequent call to chmod(3P) would end up mishandling "core.sharedRepository". Patrick
Attachment:
signature.asc
Description: PGP signature
