Subject: Re: [PATCH 3/4] builtin/clone.c: recognize fetch.serverOption configuration

From: Junio C Hamano <[email-masked]>
Date: Mon, 09 Sep 2024 08:44:55 -0700

"Xing Xin" <[email-masked]> writes:

> Given the addition of a remote.*.<subkey> configuration in Git's global
> settings, such as:
>
>     git config --global remote."*".demoConfigKey demoConfigValue
>
> The current versions of Git may produce errors with certain commands.
> For example, running `git fetch --all` will result in:
>
>     $ git fetch --all
>     Fetching *
>     fatal: '*' does not appear to be a git repository
>     fatal: Could not read from remote repository.

Ah, good point.  Anything that wants to enumerate the subkeys under
remote. hierarchy MUST be aware of the new convention.

So such a code must of course need to be updated to treat "*" as a
virtual thing and exclude from enumeration (I suspect "git remote"
has the same property), and delivered to the end-users at the same
time.

An alternative is to use remote.<key> as a fallback default for
remote.<name>.<key>, which has been done successfully for other
hierarchies like http.<url>.<key> would override http.<key> for any
defined <key>s.  So if we have remote.<name>.skipFetchAll per
remote, we could use remote.skipFetchAll as its fallback default
value.