On Mon, Sep 23, 2024 at 12:17:55PM +0000, Xing Xin via GitGitGadget wrote:
> diff --git a/Documentation/config/remote.txt b/Documentation/config/remote.txt
> index 8efc53e836d..8ba48573fb6 100644
> --- a/Documentation/config/remote.txt
> +++ b/Documentation/config/remote.txt
> @@ -95,3 +95,13 @@ remote.<name>.partialclonefilter::
> Changing or clearing this value will only affect fetches for new commits.
> To fetch associated objects for commits already present in the local object
> database, use the `--refetch` option of linkgit:git-fetch[1].
> +
> +remote.<name>.serverOption::
> + When no `--server-option=<option>` argument is given from the command
> + line, git will use the values from this configuration as a default list of
This description feels a bit inelegant to me. How about the following:
The default set of server options used when fetching from the
remote. These server options are overridden by the
`--server-option=` command line arguments.
> @@ -125,6 +126,7 @@ static struct remote *make_remote(struct remote_state *remote_state,
> struct remote *ret;
> struct remotes_hash_key lookup;
> struct hashmap_entry lookup_entry, *e;
> + struct string_list server_options = STRING_LIST_INIT_DUP;
>
> if (!len)
> len = strlen(name);
> @@ -143,6 +145,7 @@ static struct remote *make_remote(struct remote_state *remote_state,
> ret->name = xstrndup(name, len);
> refspec_init(&ret->push, REFSPEC_PUSH);
> refspec_init(&ret->fetch, REFSPEC_FETCH);
> + ret->server_options = server_options;
I was wondering at first where we actually populate the
`server_options`, until I realized that this is only done to initialize
the `ret->server_options`. I think it would be less confusing if this
used `string_list_init_dup()` instead of the local variable.
Patrick
