On June 18, 2020 4:57 PM, Matthew wrote: > > "Riddell, Matthew A" <mriddell@xxxxxxxxxxx> 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. > > We have had problems in our continuous integration environment with builds > modifying the global configuration of tools. I came across this issue trying to > lock down our git global configuration for the local user running our builds. > The workaround I found is creating a symlink from the user home directory > to another folder (which has read only permissions) which contains the > actual gitconfig file. As a suggestion, you might want to add a git status -uno --porcelain to key parts of your scripts to find the conditions where that is occurring and fail the job if the output is not empty. CI tools and applications should not change configurations unexpectedly and that would be a pipeline stage failure - in my books anyway.
