# Confusion with git config list --show-origin 3 messages from 2026-09-29 to 2026-10-02. Participants: Christophe Lohr, Patrick Steinhardt, brian m. carlson. Thread: https://gitlist.dev/t/66421 ## Christophe Lohr, 2026-09-29 12:36 Subject: Confusion with git config list --show-origin Message-ID: ``` 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? Best regards Christophe ``` ## Patrick Steinhardt, 2026-10-01 06:37 Subject: Re: Confusion with git config list --show-origin Message-ID: In-Reply-To: ``` 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. Thanks! Patrick ``` ## brian m. carlson, 2026-10-02 21:01 Subject: Re: Confusion with git config list --show-origin Message-ID: In-Reply-To: ``` 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 ```