Christian Couder <christian.couder@xxxxxxxxx> writes: > Then C might or might not, want to get the objects from X, and should > let S know about this. I only left this instance quoted in this reply, but I found that there are too many "should" in the description (both in the proposed log message and in the documentation patch), which do not help the readers with accompanying explanation on the reason why it is a good idea to follow these "should". For example, S may suggest X to C, and C (imagine a third-party reimplementation of Git, which is not bound by your "should") may take advantage of that suggestion and use X as a better connected alternative, and C might want to do so without even telling S. What entices C to tell S? IOW, how are these two parties expected to collaborate with that information at hand? Without answering that question ... > To allow S and C to agree and let each other know about C using X or > not, let's introduce a new "promisor-remote" capability in the > protocol v2, as well as a few new configuration variables: > > - "promisor.advertise" on the server side, and: > - "promisor.acceptFromServer" on the client side. ... the need for a mechanism to share that information between S and C is hard to sell. "By telling S, C allows S to omit objects that can be obtained from X when answering C's request?" or something, perhaps? > +Note that in the future it would be nice if the "promisor-remote" > +protocol capability could be used by the server, when responding to > +`git fetch` or `git clone`, to advertise better-connected remotes that > +the client can use as promisor remotes, instead of this repository, so > +that the client can lazily fetch objects from these other > +better-connected remotes. This would require the server to omit in its > +response the objects available on the better-connected remotes that > +the client has accepted. This hasn't been implemented yet though. So > +for now this "promisor-remote" capability is useful only when the > +server advertises some promisor remotes it already uses to borrow > +objects from. We need to figure out before etching the protocol specification in stone what to do when the network situations observable by C and S are different. For example, C may need to go over a proxy to reach S, S may directly have connection to X, but C cannot reach X directly, and C needs another proxy, different from the one it uses to go to S, to reach X. How is S expected to know about C's network situation, and use the knowledge to tell C how to reach X? Or is X so well known a name that it is C's responsibility to arrange how it can reach X? I suspect that this was designed primarily to allow a server to better help clients owned by the same enterprise entity, so it might be tempting to distribute pieces of information we usually do not consider Git's concern, like proxy configuration, over the same protocol. I personally would strongly prefer *not* to go in that direction, and if we agree that we won't go there from the beginning, I'd be a lot happier ;-)
