Re:Re: [PATCH v2 0/5] Support server option from configuration

>On Mon, Sep 23, 2024 at 12:17:53PM +0000, blanet via GitGitGadget wrote:
>> We have multiple internal repositories configured with a huge number of CI
>> tasks, each requiring code preparation (either via clone or fetch). These CI
>> tasks, triggered by post-receive hooks, often fetch the same code (usually
>> using --depth=1) concurrently.
>> 
>> To reduce performance impacts on the git server caused by these tasks, we
>> want to deploy a special designed pack-objects-hook. This hook would allow
>> the packs generated by git-pack-objects to be reused. Since not all
>> clone/fetch operations will benefit from this caching (e.g., pulls from
>> developers' environments), clients need to pass a special identifier to
>> indicate whether caching should be enabled for a particular operation. Using
>> server options is a suitable method for this.
>> 
>> However, server options can only be specified via the command line option
>> (via --server-option or -o), which is inconvenient and requires CI script
>> modifications. A configuration-based approach is easier to propagate (by
>> changing the global configuration ~/.gitconfig) and avoids issues with older
>> Git versions that don't support --server-option.
>> 
>> This patch series introduces a new multi-valued configuration,
>> remote.<name>.serverOption, similar to push.pushOption, to specify default
>> server options for the corresponding remote.
>> 
>>  * Patch 1~3 is the main change for introducing the new configuration.
>>  * Patch 4 fixes a issue for git-fetch not sending server-options when
>>    fetching multiple remotes.
>>  * Patch 5 is a minor fix for a server options-related memory leak.
>
>Sorry for taking this long to get back to this patch series. I've given
>it another careful read and have a single proposal for improved docs
>that you may want to address. But other than those nits this version
>looks great to me, thanks!