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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 1, 2019, 17:25 UTC
Message-ID: <xmqqbm1pvdri.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <CAP8UFD1K=n1CriNSY75MyBG7ZDYUQRq3LcEMrxTJVcyhQgyJrg@mail.gmail.com>

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

Show 21 quoted lines

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