Re: [PATCH v2 3/3] upload-pack: allow configuring a missing-action

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 1, 2024, 09:43 UTC
Message-ID: <xmqqwmn9athc.fsf@gitster.g>
In-Reply-To: <CAP8UFD18Y=NhnnzcHoBOiO7bu_VrxnHOeLgUeqiADQPcgtMW=A@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

Show 11 quoted lines

>> Hmph.  If C asks a partial clone and S is willing to be the promisor
>> for C, S is essentially saying that it will serve C any objects on
>> demand that are reachable from any object it served C in the past,
>> forever, no?  It might not get from S initially all the objects, but
>> if it wants later, S promises to let C have them.
>
> This promise is not broken, as S can still get the missing objects
> from X and then pass them to C. There is even the following test case
> in the patch that shows that it works when uploadpack.missingAction is
> unset (and thus default to "error" which is the same as how things
> currently work):

And the whole point of that configuration is to make it easier for S to break that promise, no? uploadPack.missingAction is set at S and is not under control of C, right?

Show 6 quoted lines

> So S keeps its promise to let C have any object through S if C wants.
> It's just that having large objects through S (instead of directly
> from X) is not a good idea ...
> ...
> So if it's Ok for other features to require an additional server to
> fulfill the promise, why is it not Ok in the case of S + X?

I am questioning the design that does not give C any say in the decision if it is a good idea or not to ask S relay large objects. S unilaterally decides that it does not want to and does not serve such large objects to C, and without even checking with C if it can reach X to fetch directly, silently assuming that C will do so, right? It is quite different from the contract between C and S in the simpler world.

> 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. Not doing anything and silently assuming that C will get them from elsewhere is simply irresponsible, especially if C is not even told about X over the protocol, no?