From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH] config: honor file permission bits
Date: Fri, 23 Oct 2026 07:54:13 -0700 [thread overview]
Message-ID: <xmqq8q3obh7u.fsf@gitster.g> (raw)
In-Reply-To: <atsZX6exgGJkNQQQ@pks.im> (Patrick Steinhardt's message of "Fri, 23 Oct 2026 10:23:05 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> What I wonder is what makes our config file so special compared to
> everything else that uses lockfiles. Or put differently: if we think
> it's important to honor permissions bits (which I think is sensible),
> shouldn't we do that in a central location like in "lockfile.c" so that
> all users of this interface behave the same?
The $HOME/.gitconfig file and its XDG counterparts are the only
out-of-tree files that suffer from this issue, and being outside the
repository is what makes them special. Theoretically, /etc/gitconfig
on a multi-user system could have the same issue, but the containing
directory would typically be read-only for regular users, which makes
the issue irrelevant there.
I do not see any sensible reason why a user would want to "protect"
in-tree files like .git/index from Git, either by running "chmod -w"
on them or by any other means. We make files under the .git/objects/
hierarchy read-only, but that is to prevent accidental overwriting
by tools other than Git, so it does not serve as an example of Git
needing to respect read-only bits in the general lockfile machinery.
Having said all that, the patch was intentionally isolated to the
caller's side of the API, primarily because auditing all code paths
that use the lockfile API was far beyond my available time budget.
next prev parent reply other threads:[~2026-10-23 14:54 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
2026-10-22 23:29 ` Junio C Hamano
2026-10-23 8:23 ` Patrick Steinhardt
2026-10-23 14:54 ` Junio C Hamano [this message]
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=xmqq8q3obh7u.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox