RE: Git config command ignores explicitly set file permissions

["Randall S. Becker" <rsbecker@nexbridge.com>]

On June 18, 2020 2:32 PM, Junio C Hamano wrote:
> "Riddell, Matthew A" <mriddell@paychex.com> writes:
> > I noticed while working with Git that the file permissions on the
> > gitconfig file is ignored and the parent folder permissions are used
> > instead to update the file.  An example is as follows:
> >
> > Before running git config ensure the user running the command is not
> > able to edit the file but has read access to the file. Ensure the User
> > has full access to the parent folder.  After running any git config
> > command the user previously without edit permissions on a file can now
> > edit the config file.

Forgive me to asking, but is this an attempt at replicating what other VCS
systems do? ClearCase is an example where files are forced to read-only and
if the user wants to modify it, then they have to ask nicely for a lock on
the file. The use of "read only" is a semi-guarantee that a user will not
modify code and interfere with other users. In git, the rules are quite
different, where modification resolution occurs later in the process.

> That is pretty much how things are intended to work on a filesystem and is
> not limited to Git.  Your arrangement, contrary to what you said, does not
> "ensure the user running the command is not able to edit but has read
> access".
> 
>     mkdir newdir
>     chmod +rwx newdir
>     >newdir/file
>     chmod a-w newdir/file
> 
> would not forbid you from doing
> 
>     rm -f newdir/file
>     ehco new >newdir/file
> 
> In other words, if you allow your user to write to a directory, you cannot
> forbid the user from creating and removing files in it.

Just inquiring about this, as git operational decisions are fundamentally
different from older systems.

Regards,
Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.