bug: git config --global --unset doesn't unset configs in corner case

bug: git config --global --unset doesn't unset configs in corner case

[Mike Hommey]

Hi,

When both ~/.gitconfig and ~/.config/git/config exist, git will read
both. But when using `git config --global --unset`, it will only touch
the first one. So unsetting config items from ~/.config/git/config is
not possible from the command line when ~/.gitconfig exists.

Mike

Re: bug: git config --global --unset doesn't unset configs in corner case

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

> When both ~/.gitconfig and ~/.config/git/config exist, git will read
> both. But when using `git config --global --unset`, it will only touch
> the first one. So unsetting config items from ~/.config/git/config is
> not possible from the command line when ~/.gitconfig exists.

Interesting observation of an understandable behaviour.

I think the original intent of limiting the writing to just one was
to avoid having both files in the first place.  When both do exist
already, I am not sure what the right behaviour on the write side
should be.  We could special case "--unset-all" and remove from
both, but "--unset" is to remove just one, so when the reading side
reads from both, it becomes "which one to remove"?

Comments from those who are more familiar with the "git config" are
certainly appreciated.

Thanks.

Re: bug: git config --global --unset doesn't unset configs in corner case

[Patrick Steinhardt]

[-- Attachment #1: Type: text/plain, Size: 2918 bytes --]

On Thu, May 09, 2024 at 09:23:13AM -0700, Junio C Hamano wrote:
> Mike Hommey <mh@glandium.org> writes:
> 
> > When both ~/.gitconfig and ~/.config/git/config exist, git will read
> > both. But when using `git config --global --unset`, it will only touch
> > the first one. So unsetting config items from ~/.config/git/config is
> > not possible from the command line when ~/.gitconfig exists.

This actually works as documented:

  --global

    For writing options: write to global ~/.gitconfig file rather than
    the repository .git/config, write to $XDG_CONFIG_HOME/git/config
    file if this file exists and the ~/.gitconfig file doesn’t.

    For reading options: read only from global ~/.gitconfig and from
    $XDG_CONFIG_HOME/git/config rather than from all available files.

    See also the section called “FILES”.

Whether that behaviour is sane is a different question though.

> Interesting observation of an understandable behaviour.
> 
> I think the original intent of limiting the writing to just one was
> to avoid having both files in the first place.  When both do exist
> already, I am not sure what the right behaviour on the write side
> should be.  We could special case "--unset-all" and remove from
> both, but "--unset" is to remove just one, so when the reading side
> reads from both, it becomes "which one to remove"?
> 
> Comments from those who are more familiar with the "git config" are
> certainly appreciated.

Honestly, I even think that the reading behaviour is weird. For almost
all the other tools that I know of that did the XDG migration, they only
ever read either the XDG config or the one located in the users' home
directory. I think this behaviour is quite sensible and leads to less
surprises overall, also to avoid asymmetric behaviour like the reported
one.

In any case, I find the expectation that `--unset-all` unsets all config
reasonable. But what about `--remove-section` and `--rename-section`? If
a section exists in both files, should it be renamed in both? And
removed in both? What if you set a value with a value pattern (`git
config foo.bar baz pattern`)? I think the answers are less clear in
those cases, and that to me hints that the design of how this feature
works is off.

As said, the most reasonable behaviour would be if we started to only
ever use _either_ the XDG _or_ the home config, but never both. This not
only solves the reported issue, where it's unclear which of the files
should be modified. It also solves other problems -- would you for
example know the precedence order of those two files?

I have no idea though whether this is something that we can reasonably
change now. I doubt that many users rely on having both configs, and
I cannot think of any reason why they knowingly would. But it would be a
potentially breaking change regardless of that.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: bug: git config --global --unset doesn't unset configs in corner case

[rsbecker]

On Thursday, May 9, 2024 12:23 PM, Junio C Hamano wrote:
>Mike Hommey <mh@glandium.org> writes:
>
>> When both ~/.gitconfig and ~/.config/git/config exist, git will read
>> both. But when using `git config --global --unset`, it will only touch
>> the first one. So unsetting config items from ~/.config/git/config is
>> not possible from the command line when ~/.gitconfig exists.
>
>Interesting observation of an understandable behaviour.
>
>I think the original intent of limiting the writing to just one was to
avoid having both
>files in the first place.  When both do exist already, I am not sure what
the right
>behaviour on the write side should be.  We could special case "--unset-all"
and
>remove from both, but "--unset" is to remove just one, so when the reading
side
>reads from both, it becomes "which one to remove"?
>
>Comments from those who are more familiar with the "git config" are
certainly
>appreciated.

If both ~/.gitconfig and ~/.config/git/config both exist, a scope of
--global becomes ambiguous. The --file <file> option should disambiguate the
operation if just --unset is used. Otherwise, perhaps we should fail the
operation.

--Randall