Re: Bug: git config does not respect read-only .gitconfig file

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Probably converting "rename(from, to)" to first check "access(to,
> W_OK)". That's racy, but it's the best we could do.

Hmph, if these (possibly problematic) callers are all following the
usual "lock, write to temp, rename" pattern, perhaps the lock_file()
function can have access(path, W_OK) check before it returns a
tempfile that has been successfully opened?

Having said that, I share your assessment that this is not a code or
design problem.  It is unreasonable to drop the write-enable bit of
a file in a writable directory and expect it to stay unmodified. The
W-bit on the file is not usable as a security measure, and we do not
use it as such.

I do not offhand know how much a new feature "this repository can be
modified by pushing into and fetching from, but its configuration
cannot be modified" is a sensible thing to have.  But it is quite
clear that even if we were to implement such feature, we wouldn't be
using W-bit on .git/config to signal that.