Junio C Hamano sent an RFC patch addressing a mismatch between user expectations and Git's behavior. Git updates an existing file by creating a lockfile, copying the original's permission bits and contents while making its changes, and then renaming the lockfile over the original. As a result, running chmod a-w on $HOME/.gitconfig does not stop Git from rewriting it. Making the containing directory unwritable would protect it, but Hamano called that contrary to intuition and not how one protects a regular file.
In a follow-up to a question from Patrick Steinhardt, Hamano said the user-level config files, $HOME/.gitconfig and its XDG counterparts, are the only out-of-tree files that suffer from this, and being outside the repository is what makes them special. Theoretically /etc/gitconfig on a multi-user system could have the same issue, but its directory is typically read-only for regular users.
He said he sees no sensible reason a user would want to protect in-tree files such as .git/index from Git, by chmod -w or otherwise. Files under .git/objects are made read-only, but he described that as protecting them from other tools rather than from Git itself.
Steinhardt asked what makes the config file so special compared with everything else that uses lockfiles. If honoring permission bits is important, which he considers sensible, he asked whether it should be done in a central place such as lockfile.c so that all users of the interface behave the same.
The thread has six messages, including one from brian m. carlson that the excerpts do not show. Whether the change stays in the config code or moves into lockfile.c remains open.