Re: [PATCH v2 0/3] config: read both home and xdg files for --global
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 24, 2026, 01:32 UTC
- Message-ID
- <xmqqo6esti9o.fsf@gitster.g>
- In-Reply-To
- <CAPx1GvcDNx4BUPQkVjbKxYLxTJ=StvLC43R0S_2=T0R8NKbZ7w@mail.gmail.com>
Chris Torek <chris.torek@gmail.com> writes:
Show 14 quoted lines
>> Git still reads the XDG config as part of its effective configuration, >> as shown by listing the configuration without `--global`: >> $ git config list --show-scope --show-origin >> global file:/Users/delilah/.config/git/config xdg.config=true >> global file:/Users/delilah/.gitconfig home.config=true >> >> The documentation, quoted in [1] and [2], states that `--global` should >> read from both files ... > > I have a related question: which of the global file(s) does > > git config --global --edit > > edit? Which one(s) should it edit?
I _know_ that having git-config read per-user configuration from both places was a deliberate design choice to help those who choose to migrate away from ~/.gitconfig to the XDG layout, while making sure we do not disrupt those who choose not to migrate.
For the write-out path of "git config --global set var val", we also chose accordingly, knowing that the majority of users back then had their per-user configuration in ~/.gitconfig and some, but not necessarily all, wanted to migrate to the XDG layout, while avoiding writing the same thing twice to different places. Therefore, "git config --global --edit" should follow the choice in the same spirit as the existing write-out code path (and no, I do not think we want to open two files in users' editors).
As to the primary focus of this topic, I think "git config --global" for the read path was not designed as carefully as the write-out code path or the general "git config" sequence when we introduced optional support for the XDG layout. Any discrepancy between "git config" when reading per-user values (to be overridden further by per-repository settings) and what "git config --global" reads from per-user files is very likely not due to any deliberate design choice, but merely bugs caused by a slip of the mind.