From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH] config: honor file permission bits
Date: Thu, 22 Oct 2026 21:08:15 +0000 [thread overview]
Message-ID: <atp7Pvtp1rdL8Uj_@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqpkx1e9iq.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]
next prev parent reply other threads:[~2026-10-22 21:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 14:27 [RFC/PATCH] config: honor file permission bits Junio C Hamano
2026-10-22 20:59 ` Junio C Hamano
2026-10-22 21:08 ` brian m. carlson [this message]
2026-10-22 23:29 ` Junio C Hamano
2026-10-23 8:23 ` Patrick Steinhardt
2026-10-23 14:54 ` Junio C Hamano
2026-10-26 8:40 ` Patrick Steinhardt
2026-10-26 15:01 ` Junio C Hamano
2026-10-26 14:59 ` [PATCH v2] " Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atp7Pvtp1rdL8Uj_@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.