Re: [PATCH] repo-settings: fix checking for fetch.negotiationAlgorithm=default

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jan 31, 2022, 21:03 UTC
Message-ID: <220131.864k5jbo5h.gmgdl@evledraar.gmail.com>
In-Reply-To: <CABPp-BHcS3nwupJSORUuVeVhGzrL3VqPm4YQSr7G-JuyLaqBpQ@mail.gmail.com>

On Mon, Jan 31 2022, Elijah Newren wrote:

Show 35 quoted lines

> On Mon, Jan 31, 2022 at 8:57 AM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
>> >> I.e. =default should always be equivalent to not declaring that config
>> >> at all anywhere, and not drift to being a reference to some name that
>> >> happens to be "default", as in the GNOME case.
>> >
>> > No, we have the same problem as the Gnome case.  See this part of the
>> > documentation for fetch.negotiationAlgorithm:
>> >
>> > """
>> >     The default is "default" which instructs Git to use the
>> >     default algorithm that never skips commits (unless the server has
>> >     acknowledged it or one of its descendants).
>> > """
>>
>> That looks more like one of the bugs introduced when skipping was
>> turned on for the "experimental" folks.  To fix this, without
>> turning skipping into the default too hastily, there needs two and
>> half things to happen:
>>
>>  * Give a new name for the non-skipping algorithm, and describe the
>>    algorithm like the above.
>>
>>  * Describe "default" is "non-skipping" but "feature.experimental"
>>    makes "skipping" the default.
>>
>>  * Support "non-skipping" in the configuration parser, so that even
>>    when something else becomes the default, people can choose it.
>>
>> I would think.
>
> Sounds good to me.  I'm not very creative, so I think I'd just use
> "non-skipping" as the new name.

I can't think of a better one either (aside from my already-suggested "exhaustive"), but that's naming it in terms of the only other negotiator.

Is it the case that the only thing anyone would want to tweak about the default one is its skipping behavior?

E.g. if we were to make one called "smart-topology" or something (would skip sending some OIDs by assuming things about branch/tag topology, i.e. if you have X that probably includes Y) having negotiators "A", "non-A", and "C" would be odd :)

We're unlikely to change the "default" negotiatior behavior at this point, so maybe some label that communicates "the old one" without implying deprecation? Perhaps "classic"?