On Wed, Sep 04, 2024 at 03:49:28PM +0800, Xing Xin wrote:

At 2024-09-03 18:09:45, "Patrick Steinhardt" [off-list ref] wrote:

quoted

On Mon, Sep 02, 2024 at 12:13:55PM +0000, Xing Xin via GitGitGadget wrote:

quoted

diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 8e925db7e9c..105645ed685 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt

@@ -149,6 +149,9 @@ objects from the source repository into a pack in the cloned repository.
 	unknown ones, is server-specific.
 	When multiple ++--server-option=++__<option>__ are given, they are all
 	sent to the other side in the order listed on the command line.
+	When no ++--server-option=++__<option>__ is given from the command
+	line, the values of configuration variable `fetch.serverOption`
+	are used instead.
 
 `-n`::
 `--no-checkout`::

I'm not a 100% sure, but I don't think that `fetch.*` configs typically
impact git-clone(1). So this here is a tad surprising to me.

It makes me wonder whether it is actually sensible to implement this as
part of the `fetch` namespace in the first place. I'm not yet quite sure
where this whole series slots in, that is why one would want to set up
default server options in the first place. So what I'm wondering right
now is whether the server options are something that you want to apply
globally for all remotes, or whether you'd rather want to set them up
per remote.

Sorry for not explaining our use case clearly. We have several internal
repositories configured with numerous CI tasks, each requiring code
preparation (sometimes via clone, sometimes via fetch). These CI tasks
are ususally triggered by post-receive hook, so the concurrent tasks are
actually fetching the same copy of code.

On git server, we want to deploy a special pack-objects-hook to mitigate
the performance impacts caused by these CI tasks (so the packfile
produced by git-pack-objects can be reused).  Since not all clone/fetch
operations can benefit from this caching mechanism (e.g. pulls from
users' dev environment), we need the client to pass a special identifier
to inform the server whether caching support should be enabled for that
clone/fetch. Clearly, using server options is a good choice.

To achieve our design, we need to add two patch series to git:

1. Support injecting server options to identify environments via
   configuration, because adding the --server-option parameter would
   require too many script modifications, making it difficult to deploy.
   This is what this patch series does.
2. Git server should pass the received server options as environment
   variables (similar to push options) to the pack-objects-hook.

When you talk about client, do you mean that the actual users will have
to configure this? That sounds somewhat unmaintainable on your side from
the surface. I guess I ain't got enough knowledge around the environment
you operate in though, so I probably shouldn't judge.

quoted

In the latter case I could see that it may make sense to instead make
this `remote.<name>.serverOption`. This would also remove the unclean

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

Patrick