Git should be able to discover one or more bundle servers associated with a given repository. There are really two scenarios here: one for human users and another for automation such as a CI worker.
Human users
When I clone a repository, I would like to rely on a bundle server that's "nearby" (in a network sense) and functional (responding, not overloaded, etc.). The Git server could advertise bundle servers that it knows about. The client could then perform probes or other logic to decide which one to use. The client might be a wrapper around Git or some kind of contrib/ addition to Git if the changes can't be added to core Git.
A decent fallback would be the ability to advertise a single bundle server. Then, deployments could set up a GeoDNS-style system to automatically routes clients to different server instances.
CI etc.
CI workers are often clones of a base image. The image could be preconfigured to route all Git requests to a bundle server, ideally with the ability to route by hostname. For illustrative purposes, something like the way SSH config is done:
Host ghes.mycompany.example.com
UseBundleServer yes
BundleServer gitbundle.mycompany.example.com
Host publicforge.example.net
UseBundleServer no
In concert with the client heuristics mentioned earlier, this might be extended to have multiple possible bundle servers that the worker can choose from:
Git should be able to discover one or more bundle servers associated with a given repository. There are really two scenarios here: one for human users and another for automation such as a CI worker.
Human users
When I clone a repository, I would like to rely on a bundle server that's "nearby" (in a network sense) and functional (responding, not overloaded, etc.). The Git server could advertise bundle servers that it knows about. The client could then perform probes or other logic to decide which one to use. The client might be a wrapper around Git or some kind of
contrib/addition to Git if the changes can't be added to core Git.A decent fallback would be the ability to advertise a single bundle server. Then, deployments could set up a GeoDNS-style system to automatically routes clients to different server instances.
CI etc.
CI workers are often clones of a base image. The image could be preconfigured to route all Git requests to a bundle server, ideally with the ability to route by hostname. For illustrative purposes, something like the way SSH config is done:
In concert with the client heuristics mentioned earlier, this might be extended to have multiple possible bundle servers that the worker can choose from:
(These examples aren't meant to specify syntax. I assume we'd find a way to put it into
gitconfigsyntax.)