On Mon, Jan 31, 2022 at 1:17 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > On Mon, Jan 31 2022, Elijah Newren wrote: > > > On Mon, Jan 31, 2022 at 8:57 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> > >> Elijah Newren <newren@xxxxxxxxx> 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"? Oh, sorry for forgetting your "exhaustive" suggestion; sometimes weekends do that to you. I actually like that suggestion of yours a bit better. classic could also work. Maybe Jonathan also has ideas/preferences, since he wrote the "skipping" code?
