Git Config Precedence Tester

Because extensions.worktreeConfig is not true in .git/config — and, less obviously, because setting it from a file that .git/config includes does not count either. git reads the repository format from that one file without following includes, so the extension has to be written into .git/config literally. git config --worktree and git worktree do that for you, which is why the file usually works when you did not create it by hand. The documentation also tells you to raise core.repositoryFormatVersion to 1 alongside it; git 2.43 reads the worktree file even at version 0, so a version-0 repository with the extension set is not the bug you are hunting. This page reproduces that behaviour and flags the version mismatch separately, because an older git on another machine may well ignore the file.

System, then global, then local, then worktree, then the command line. This page covers the four file scopes. The command line is git -c key=value …, the GIT_CONFIG_KEY_n and GIT_CONFIG_VALUE_n environment pairs, and options a porcelain command passes to itself; none of that lives in a file you can paste, and git config --list --show-scope labels it command line. If a key resolves one way here and another way on the real machine, that gap is the first place to look. GIT_CONFIG_SYSTEM, GIT_CONFIG_GLOBAL and GIT_CONFIG_NOSYSTEM are a different mechanism again: they replace or suppress a file scope rather than adding a new one on top.

No, and that is a real way to end up with two remotes. Section and key names are case-insensitive and git prints them folded to lower case, so [CORE] BigFileThreshold comes back as core.bigfilethreshold. A subsection in double quotes is compared byte for byte, so [remote "Origin"] and [remote "origin"] are two different remotes and git remote -v lists both. The deprecated dotted form [section.SubSection] is the exception: the whole header is read as one token and folded, so it becomes section.subsection and answers to a lower-case query. This page implements both, which is why a config using the dotted form resolves where the quoted form does not.

A gitdir: pattern is matched against the .git directory path, not the working tree, and the match is a glob over the whole path rather than a prefix test — so ~/work matches only a git directory literally called ~/work. You want ~/work/, where the trailing slash expands to ~/work/** and catches everything underneath. Three more rules are worth memorising: a pattern that is neither absolute nor ~/ nor ./ gets **/ prepended, so gitdir:acme/ matches an acme directory anywhere on the disk; ./ is relative to the file holding the condition, which is what makes a .gitconfig dropped into a projects folder self-contained; and gitdir/i: is the same match without case, which is what you want on macOS and Windows.

Because a key can be set more than once and git keeps every occurrence in read order. --get hands you the last one, which is what nearly all of git uses; --get-all hands you the whole list. Some keys are meaningless without the list: remote.origin.fetch is normally two or three refspecs, safe.directory is a list by design, and include.path is however many files you chained. That is also why writing such a key with git config remote.origin.fetch … replaces a single entry instead of adding one, and why --add, --replace-all and --unset-all exist at all. The overridden column here shows every earlier candidate with the file and line it came from, so you can see whether a value was replaced or merely joined.

Neither can git, and that is the point of showing it this way. A config file is parsed as one stream, and any byte the parser cannot place — an unterminated [section header, a space inside a key name, an unmatched double quote, an unknown backslash escape — makes the entire read fatal: git config --list prints nothing, and every command that reads configuration fails the same way, usually complaining about a file you were not editing. The line reported is where the offending statement began. The one thing that looks broken and is not is a key written before any section header: orphan = 1 at the top of a file parses fine and appears in --list as a bare orphan, but git config --get orphan refuses it because a query has to name a section, so the value is unreachable rather than invalid.