Junio C Hamano <gitster@xxxxxxxxx> writes: > Christian Couder <christian.couder@xxxxxxxxx> writes: > >> When a server repository S borrows some objects from a promisor remote X, >> then a client repository C which would like to clone or fetch from S might, >> or might not, want to also borrow objects from X. Also S might, or might >> not, want to advertise X as a good way for C to directly get objects from, >> instead of C getting everything through S. > > If S is a clone that is keeping up to date with X, even if it does > not borrow anything from X, as long as X is known to be much better > connected to the world (e.g., it is in a $LARGEINTERNETCOMPANY > datacenter with petabit/s backbone connections) than S is (e.g., it > is my deskside box on a cable modem), it may be beneficial if S can > omit objects from its "git fetch" response to C, if C is willing to > fill the gap using X. > > So it is of dubious value to limit the feature only to cases where S > "borrows" from X, is it? An even better example is if S on my deskside box is the source of truth, and X in $LARGEINTERNETCOMPANY datacenter that is much better connected is a publishing repository I use to push from S to X. Even if you originally cloned from S and use S as your promisor remote, as the operator of S, I would like you to always consult X first to reduce the load on S when lazily fetching objects that you are missing.
