Re: [PATCH v3 05/11] promisor-remote: use repository_format_partial_clone

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

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

> On Wed, Mar 13, 2019 at 5:31 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Christian Couder <christian.couder@gmail.com> writes:
>>
>> > A remote specified using the extensions.partialClone config
>> > option should be considered a promisor remote too.
>> >
>> > This remote should be at the end of the promisor remote list,
>> > so that it is used only if objects have not been found in other
>> > remotes.
>>
>> That's a declaration, not a rationale, and does not answer "Why
>> should the origin be only used as the last resort?".
>
> I have added the following explanation:
>
>     If we are using promisor remotes other than the origin, it is
>     because these other promisor remotes are likely to be better
>     for some reason (maybe they are closer or faster for some kind
>     of objects) than the origin, so it's logical that we try to use
>     them first.

Alternatively, perhaps you cloned from the origin repository which
is a mirror that is not as reliable as the real thing but is faster
to access when it _is_ up, and you added the true source that
'origin' mirrors from as the fallback, as it should only be used
when 'origin' is down.

So what you wrote is not a convincing explanation why we should
treat the origin as the fallback.

Writing in the end-user documentation something like "because the
'origin' remote is treated as the last resort fallback repository,
after consulting other promisor remotes first and failing to obtain
needed objects, you may want to use repositories with better
availability listed as 'other promisor remotes' and set the worst
connected remote as 'origin'" may be a valid thing to do, though.

I do not like to see the tool making such a policy decision for
users very much, but at least by honestly documenting, we explain
what we unilaterally decide to do without having a strong
justification (i.e. we could decide the other way and the decision
would be equally valid, and because there is no single best choice,
we arbitrarily picked one) to the users, and with that, they can
adjust their use case to what the tool does to take advantage of the
tool's design decision.