Re: How to resume broke clone ?

This discussion has mostly been about letting small Git servers delegate the work of an initial clone to a beefier server. I haven't seen any explicit mention of the inverse:

Suppose a company has a central Git server that is meant to be the "single source of truth", but has worldwide offices and wants to locate bootstrap mirrors in each office. The end users would not even want to know that there are multiple servers. Hosters like GitHub might also encourage their big customers to set up bootstrap mirror(s) in-house to make cloning faster for their users while reducing internet traffic and the burden on their own infrastructure. The goal would be to make the system transparent to users and easily reconfigurable as circumstances change.

One alternative would be to ask users to clone from their local mirror.
 The local mirror would give them whatever it has, then do the
equivalent of a permanent redirect to tell the client "from now on, use
the central server" to get the rest of the initial clone and for future
fetches.  But this would require users to know which mirror is "local".

A better alternative would be to ask users to clone from the central server. In this case, the central server would want to tell the clients to grab what they can from their local bootstrap mirror and then come back to the central server for any remainders. The trick is that which bootstrap mirror is "local" would vary from client to client.

I suppose that this could be implemented using what you have discussed by having the central server direct the client to a URL that resolves differently for different clients, CDN-like. Alternatively, the central Git server could itself look where a request is coming from and use some intelligence to redirect the client to the closest bootstrap mirror from its own list. Or the server could pass the client a list of known mirrors, and the client could try to determine which one is closest (and reachable!).

I'm not sure that this idea is interesting, but I just wanted to throw it out there as a related use case that seems a bit different than what you have been discussing.

Michael