From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Patrick Steinhardt <ps@pks.im>
Cc: Christophe Lohr <christophe.lohr@cegetel.net>, git@vger.kernel.org
Subject: Re: Confusion with git config list --show-origin
Date: Fri, 2 Oct 2026 21:01:02 +0000 [thread overview]
Message-ID: <asAbjl-3IIbGKGkA@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <ar3_jVZPdgKSZJF2@pks.im>
[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]
On 2026-10-01 at 06:37:01, Patrick Steinhardt wrote:
> On Tue, Sep 29, 2026 at 02:36:20PM +0200, Christophe Lohr wrote:
> > Hello,
> > The 'git config list --show-origin' command is very useful for
> > understanding where the settings come from.
> > This command lists the files involved, specifying the full path for each
> > one,
> > except for '.git/config'
> >
> > This gives the impression that there is a '.git/' directory in the current
> > working directory, even though it isn't located here but higher up in the
> > directory tree.
> > So, may I suggest, that this command display the full path to the
> > .git/config file used by the current git command?
>
> I agree that this is quite confusing. I'm a bit torn on whether the
> consequence of that is that the resulting path should be an absolute
> one. But at the very least, in the case where we're not in the root of
> the Git repository there is a good case to be made that we should adapt
> the relative path to be relative to the current working directory and
> not to the top-level directory of the repository.
>
> One thing I wonder about though is whether that would break any users
> out there. I think it's unlikely that any scripts out there parse the
> output. But if they do, they may have long since learned that the
> repository-local file is always specified relative to the top-level
> directory of the repository. And if we were to change that now, then
> those scripts may break.
>
> As I said, I think the risk of breakage is comparatively low. But I'd be
> curious to learn what others think about this.
I think it would be fine to specify it as an absolute path, provided
it's canonicalized (symlink-free). We already do that for other paths
in the output, so callers already have to deal with that case.
There is certainly the possibility of breakage, but I agree it's likely
low. It's also not hard to do something like `git rev-parse
--path-format=absolute --git-path config` to find out which file is the
local file among multiple.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]
prev parent reply other threads:[~2026-10-02 21:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 12:36 Confusion with git config list --show-origin Christophe Lohr
2026-10-01 6:37 ` Patrick Steinhardt
2026-10-02 21:01 ` brian m. carlson [this message]
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=asAbjl-3IIbGKGkA@fruit.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=christophe.lohr@cegetel.net \
--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 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.