On Tue, Oct 08, 2024 at 03:38:14AM +0000, blanet via GitGitGadget wrote: > We manage some internal repositories with numerous CI tasks, each requiring > code preparation through git-clone or git-fetch. These tasks, triggered by > post-receive hooks, often fetch the same copy of code concurrently using > --depth=1, causing extremely high load spikes on our Git servers. > > To reduce performance impacts caused by these tasks, we plan to deploy a > specially designed pack-objects-hook [1]. This hook would allow the packs > generated by git-pack-objects(during git-clone or git-fetch) to be reused. > Since not all clone/fetch operations will benefit from this caching (e.g., > pulls from developer environments), clients need to pass a special > identifier to indicate whether caching should be enabled. Using server > options [2] is suitable for this purpose. > > However, server options can only be specified via the command line option > (via --server-option or -o), which is inconvenient and requires > modifications to CI scripts. A configuration-based approach is preferable, > as it can be propagated through global configuration (e.g. ~/.gitconfig) and > avoids compatibility 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. > > * Patches 1~3 contain the main changes for introducing the new > configuration. > * Patch 4 fixes a issue for git-fetch not sending server-options when > fetching from multiple remotes. > * Patch 5 is a minor fix for a server options-related memory leak. > > 1. https://git-scm.com/docs/git-config#Documentation/git-config.txt-uploadpackpackObjectsHook > 2. https://git-scm.com/docs/gitprotocol-v2#_server_option The range-diff looks as expected to me, so this should be ready to go from my point of view. Thanks! Patrick
