From: Xing Xin Date: Mon, 09 Sep 2024 02:50:21 GMT Subject: Re:Re: Re: Re: [PATCH 3/4] builtin/clone.c: recognize fetch.serverOption configuration Message-ID: <3a7b1ced.364e.191d4b07a1a.Coremail.bupt_xingxin@163.com> In-Reply-To: At 2024-09-05 21:44:41, "Patrick Steinhardt" wrote [snip] >> >> I named the new configuration `fetch.serverOption` mainly to follow the >> >> `push.pushOption` pattern. Since which server options to support is >> >> actually server-specific, using `remote..serverOption` is a good >> >> idea for git-fetch. However, how should we design the configuration for >> >> git-ls-remote or git-clone, if we wanna provide all of them with a >> >> default list of server options to send? >> > >> >As mentioned in another reply, I think that putting this into the remote >> >configuration "remote.*.serverOption" might be a better solution, as it >> >also brings you the ability to set this per remote by default. >> >> I agree that using "remote.*.serverOption" is better. In fact, I also >> think "push.pushOption" would be better as "remote.*.pushOption". What I'm >> contemplating is whether we need to add a configuration for a default >> list of server options, so that when "remote.origin.serverOption" is not >> present, we can fall back to use that as default. > >Junio proposed in [1] to introduce `[remote "*"]` syntax to supply >default values to all remotes. You could pick up that proposal and >implement it as part of your patch series. Given the addition of a remote.*. 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. Please make sure you have the correct access rights and the repository exists. error: could not fetch * Fetching origin This raises the question of whether this can be defined as an incompatibility or whether this is acceptable. If it isn't, I prefer using a `remote.defaultServerOption` instead, as it aligns with our existing use of `remote.pushDefault` anyway. [snip] Xing Xin