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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 9, 2024, 15:44 UTC
Message-ID: <xmqq7cbkvnk8.fsf@gitster.g>
In-Reply-To: <3a7b1ced.364e.191d4b07a1a.Coremail.bupt_xingxin@163.com>

"Xing Xin" <bupt_xingxin@163.com> writes:

Show 12 quoted lines

> 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.