Thread (5 messages) 5 messages, 4 authors, 2022-02-01

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

From: Elijah Newren <hidden>
Date: 2022-01-31 21:48:09

On Mon, Jan 31, 2022 at 1:17 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
On Mon, Jan 31 2022, Elijah Newren wrote:
quoted
On Mon, Jan 31, 2022 at 8:57 AM Junio C Hamano [off-list ref] wrote:
quoted
Elijah Newren [off-list ref] writes:
quoted
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help