From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 09 Sep 2024 15:44:55 GMT
Subject: Re: [PATCH 3/4] builtin/clone.c: recognize fetch.serverOption configuration
Message-ID: <xmqq7cbkvnk8.fsf@gitster.g>
In-Reply-To: <3a7b1ced.364e.191d4b07a1a.Coremail.bupt_xingxin@163.com>

"Xing Xin" <bupt_xingxin@163.com> 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.