On 2026-10-22 at 20:59:57, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Because our updates to an existing file almost never makes
> > modifications in place, and instead create a new "lockfile",
> > propagate the permission bits from the original, copy the contents
> > from the original file while tweaking the contents as needed, and
> > then finally rename the lockfile to replace the original file, you
> > cannot "protect" your .global configuration file from accidental
> > clobbering by doing something like this:
> >
> > 	$ chmod a-w $HOME/.gitconfig
> >
> > Of course, if you make your $HOME directory unwritable, it may
> > protect your .gitconfig from getting updated, but that goes totally
> > against the intuition and is not how you would protect a regular
> > file from getting overwritten.
> >
> > Teach the configuration file writing machinery to inspect the
> > permission bits of the original with access(2) and refrain from
> > doing the usual "write a lockfile and replace the original with it"
> > dance ourselves when we shouldn't be able to write it.
> >
> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
> > ---
> >  config.c          | 22 ++++++++++++++++++++++
> >  t/t1300-config.sh | 30 ++++++++++++++++++++++++++++++
> >  2 files changed, 52 insertions(+)
> 
> Hmph, no responses to this RFC.  I somehow find it hard to believe
> that I was the only person who got annoyed by this behaviour [*].

Sorry, I looked but forgot to respond.  It seems sensible to me.

I don't personally make that file read-only, so it doesn't affect me at
all; instead, I just overwrite it with my personal configuration every
time I deploy my dotfiles.  I still think it's a reasonable thing to do
to help those who need it, though.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA