All, I recently discovered that `git config` does not respect read-only files. This caused unexpected difficulty in managing the global .gitconfig for a system account shared by a large team. A team member was able to execute a `git config --global` command without any notice or warning that the underlying config file had been marked read-only in an attempt to prevent unintentional changes. If instead git had raised a warning saying that the "gitconfig is read-only" this would have prevented that team member from accidentally breaking our git config. Bug detail: Due to the implementation strategy of config::git_config_set_multivar_in_file_gently ( https://github.com/git/git/blob/5b33cb1fd733f581da07ae8afa7e9547eafd248e/config.c#L2074 ) the file permissions of the target .gitconfig file are not respected. Proposal: Part 1) Add a .gitconfig variable to respect a read-only gitconfig file and optional "--force" override option for the `git config` command Such a gitconfig variable could be defined as: config.respectFileMode: [ "never", "allow-override", "always" ] Where: * never - read-only file mode of config files are ignored (aka: existing behavior) * allow-override - read-only file mode of config files is respected unless the user provides a "--force" option to `git config` * always - read-only file mode of config files is respected (and the "--force" option does not work) Part 2) Change config::git_config_set_multivar_in_file_gently ( https://github.com/git/git/blob/5b33cb1fd733f581da07ae8afa7e9547eafd248e/config.c#L2077 ) to verify write permissions on the destination depending on the specified config.respectFileMode variable and "--force" option. I think that this is a reasonably sized change that enables users to opt-in to a 'strict mode' while preserving current behavior. Thoughts? Tested with: OS: Linux Version: 2.9.0 (issue exists in current master branch)