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

>
> On Mon, Jan 31 2022, Elijah Newren wrote:
>
> > 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"?