On Sat, Jun 1, 2024 at 11:43 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Christian Couder <christian.couder@xxxxxxxxx> writes: > > I don't understand why you compare this to a "broken" implementation > > of promisor remotes. What could then be a non-broken one that would > > store large blobs on a separate server in your opinion? I am really > > interested in answers to this question. It's not a rhetorical one. > > You as S would tell C "I want you to go to X because I am not > serving objects X and Y". Or at least make sure that C knows about > X before deciding to omit what X ought to have. Ok, so if there was a way for S to suggest config options and perhaps also command line options to C (like I mentioned in a previous email), and if S would suggest C to configure X as a promisor remote and C would accept to do that, then it would be fine for the feature to work, right? Alternatively, if C would pass a new option called for example --known-promisor=X on top of all other options, then that could be Ok too?
