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

[Junio C Hamano <gitster@pobox.com>]

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

>> 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?

> 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?