Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

repo-settings: fix checking for fetch.negotiationAlgorithm=default #1131

Conversation

newren
Copy link

@newren newren commented Jan 26, 2022

This regression is not new in v2.35; it first appeared in v2.34. So, not urgent.

Changes since v3:

  • 'consecutive' is used as the traditional default. 'default' means either 'consecutive' or 'skipping' depending on feature.experimental.

Changes since v2:

  • Also fix the fact that fetch.negotationAlgorithm=$BOGUS_VALUE no longer errors out (yet another regression, this one dating back to v2.24.0), and add a test to make sure we don't regress it again.
  • Add 'consecutive' as a synonym for 'default', and remove 'default' from the documentation to guide people towards using 'consecutive' when they want the classic behavior.

Changes since v1:

  • Put the common code in two testcases into a function, and then just invoked it from each

cc: Derrick Stolee dstolee@microsoft.com
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com
cc: Elijah Newren newren@gmail.com
cc: Jonathan Tan jonathantanmy@google.com

@newren
Copy link
Author

newren commented Jan 28, 2022

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 28, 2022

Submitted as pull.1131.git.1643334969216.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v1

To fetch this version to local tag pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v1

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 28, 2022

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Fri, Jan 28 2022, Elijah Newren via GitGitGadget wrote:

> From: Elijah Newren <newren@gmail.com>
>
> In commit 3050b6dfc75d (repo-settings.c: simplify the setup,
> 2021-09-21), the branch for handling fetch.negotiationAlgorithm=default
> was deleted.  Since this value is documented in
> Documentation/config/fetch.txt, restore the check for this value.
>
> Note that this change caused an observable bug: if someone sets
> feature.experimental=true in config, and then passes "-c
> fetch.negotiationAlgorithm=default" on the command line in an attempt to
> override the config, then the override is ignored.  Fix the bug by not
> ignoring the value of "default".

This fix looks good, thanks for fixing my mess.

> Technically, before commit 3050b6dfc75d, repo-settings would treat any
> fetch.negotiationAlgorithm value other than "skipping" or "noop" as a
> request for "default", but I think it probably makes more sense to
> ignore such broken requests and leave fetch.negotiationAlgorithm with
> the default value rather than the value of "default".  (If that sounds
> confusing, note that "default" is usually the default value, but when
> feature.experimental=true, "skipping" is the default value.)
>
> [...]
>     A long sidenote about naming things "default":
>     
>     Many years ago, in the Gnome community, there was a huge fight that
>     erupted, in part due to confusion over "default". There was a journalist
>     who had been a designer in a past life, who had a little friction with
>     the rest of the community, but intended well and generally improved
>     things. At some point, they suggested some changes to improve the
>     "default" theme (and they were a nice improvement), but not being a
>     developer the changes weren't communicated in the form of a patch. And
>     the changes accidentally got applied to the wrong theme: the default one
>     (yes, there was a theme named "default" which was not the default
>     theme). Now, basically no one used the default theme because it was so
>     hideously ugly. I think we suffered from a case of not being able to
>     change the default (again?) because no one could get an agreement on
>     what the default should be. Who did actually use the default theme,
>     though? The person writing the release notes (though they only used it
>     for taking screenshots to include in the release notes, and otherwise
>     used some other theme). So, with people under pressure for an imminent
>     release, there were screenshots that looked like garbage, and
>     investigation eventually uncovered that it was due to changes that were
>     meant for the "default" theme having accidentally been applied to the
>     default theme. It could have just been an amusing story if not for the
>     other unfortunate factors happening around the same time and the heated
>     and protracted flamewars that erupted.
>     
>     Don't name settings/themes/things "default" if it describes something
>     specific, since someone may come along and decide that something else
>     should be the default, and then you're stuck with a non-default
>     "default". Sadly, the name was already picked and documented so for
>     backward compatibility we need to support it...

Funny story, I think this is only going to bite us if we don't switch
the default over along with promoting this out of feature.experimental.

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.

In our case it's more of a story about the inconsistencies in our config
space, i.e. some values you can't reset at all, some take empty values
to do so, others "default" etc.

> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index f0dc4e69686..37958a376ca 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
> @@ -928,6 +928,7 @@ test_expect_success 'fetching deepen' '
>  '
>  
>  test_expect_success 'use ref advertisement to prune "have" lines sent' '
> +	test_when_finished rm -rf clientv0 clientv2 &&
>  	rm -rf server client &&
>  	git init server &&
>  	test_commit -C server both_have_1 &&
> @@ -960,6 +961,45 @@ test_expect_success 'use ref advertisement to prune "have" lines sent' '
>  	! grep "have $(git -C client rev-parse both_have_2^)" trace
>  '
>  
> +test_expect_success 'same as last but with config overrides' '

Since it's the same as the preceding test, maybe we can squash this in
to avoid the duplication? This works for me.

diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 37958a376ca..3fb20eeec7e 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -927,7 +927,7 @@ test_expect_success 'fetching deepen' '
 	)
 '
 
-test_expect_success 'use ref advertisement to prune "have" lines sent' '
+test_negotiation_algorithm_default () {
 	test_when_finished rm -rf clientv0 clientv2 &&
 	rm -rf server client &&
 	git init server &&
@@ -946,7 +946,7 @@ test_expect_success 'use ref advertisement to prune "have" lines sent' '
 
 	rm -f trace &&
 	cp -r client clientv0 &&
-	GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv0 \
+	GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv0 $@ \
 		fetch origin server_has both_have_2 &&
 	grep "have $(git -C client rev-parse client_has)" trace &&
 	grep "have $(git -C client rev-parse both_have_2)" trace &&
@@ -954,50 +954,17 @@ test_expect_success 'use ref advertisement to prune "have" lines sent' '
 
 	rm -f trace &&
 	cp -r client clientv2 &&
-	GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv2 -c protocol.version=2 \
+	GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv2 -c protocol.version=2 $@ \
 		fetch origin server_has both_have_2 &&
 	grep "have $(git -C client rev-parse client_has)" trace &&
 	grep "have $(git -C client rev-parse both_have_2)" trace &&
 	! grep "have $(git -C client rev-parse both_have_2^)" trace
-'
-
-test_expect_success 'same as last but with config overrides' '
-	test_when_finished rm -rf clientv0 clientv2 &&
-	rm -rf server client &&
-	git init server &&
-	test_commit -C server both_have_1 &&
-	git -C server tag -d both_have_1 &&
-	test_commit -C server both_have_2 &&
-
-	git clone server client &&
-	test_commit -C server server_has &&
-	test_commit -C client client_has &&
-
-	# In both protocol v0 and v2, ensure that the parent of both_have_2 is
-	# not sent as a "have" line. The client should know that the server has
-	# both_have_2, so it only needs to inform the server that it has
-	# both_have_2, and the server can infer the rest.
-
-	rm -f trace &&
-	rm -rf clientv0 &&
-	cp -r client clientv0 &&
-	GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv0 \
-		-c feature.experimental=true \
-		-c fetch.negotiationAlgorithm=default \
-		fetch origin server_has both_have_2 &&
-	grep "have $(git -C client rev-parse client_has)" trace &&
-	grep "have $(git -C client rev-parse both_have_2)" trace &&
-	! grep "have $(git -C client rev-parse both_have_2^)" trace &&
+}
 
-	rm -f trace &&
-	cp -r client clientv2 &&
-	GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv2 -c protocol.version=2 \
+test_expect_success 'use ref advertisement to prune "have" lines sent' '
+	test_negotiation_algorithm_default \
 		-c feature.experimental=true \
-		-c fetch.negotiationAlgorithm=default \
-		fetch origin server_has both_have_2 &&
-	grep "have $(git -C client rev-parse client_has)" trace &&
-	grep "have $(git -C client rev-parse both_have_2)" trace &&
-	! grep "have $(git -C client rev-parse both_have_2^)" trace
+		-c fetch.negotiationAlgorithm=default
 '
 
 test_expect_success 'filtering by size' '

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 29, 2022

On the Git mailing list, Elijah Newren wrote (reply to this):

Hi Ævar,

On Thu, Jan 27, 2022 at 11:54 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> On Fri, Jan 28 2022, Elijah Newren via GitGitGadget wrote:
>
> > From: Elijah Newren <newren@gmail.com>
> >
> > In commit 3050b6dfc75d (repo-settings.c: simplify the setup,
> > 2021-09-21), the branch for handling fetch.negotiationAlgorithm=default
> > was deleted.  Since this value is documented in
> > Documentation/config/fetch.txt, restore the check for this value.
> >
> > Note that this change caused an observable bug: if someone sets
> > feature.experimental=true in config, and then passes "-c
> > fetch.negotiationAlgorithm=default" on the command line in an attempt to
> > override the config, then the override is ignored.  Fix the bug by not
> > ignoring the value of "default".
>
> This fix looks good, thanks for fixing my mess.

No worries, it was a pretty tiny mess.  It was actually caught by
testing rather than by an end user.  (I hadn't updated our internal
Git distribution since before v2.34 due to various other priorities.
Since that distribution includes some patches that turn on
feature.experimental, along with one testsuite change to explicitly
request "default" handling in a test that was intended to check the
"default" behavior, when I updated the distribution, that testcase
failed.)

And you made the code in repo-settings.c *so* much nicer to read.  I
think that's more important than this little issue.

>> > Technically, before commit 3050b6dfc75d, repo-settings would treat any
> > fetch.negotiationAlgorithm value other than "skipping" or "noop" as a
> > request for "default", but I think it probably makes more sense to
> > ignore such broken requests and leave fetch.negotiationAlgorithm with
> > the default value rather than the value of "default".  (If that sounds
> > confusing, note that "default" is usually the default value, but when
> > feature.experimental=true, "skipping" is the default value.)
> >
> > [...]
> >     A long sidenote about naming things "default":
> >
> >     Many years ago, in the Gnome community, there was a huge fight that
> >     erupted, in part due to confusion over "default". There was a journalist
> >     who had been a designer in a past life, who had a little friction with
> >     the rest of the community, but intended well and generally improved
> >     things. At some point, they suggested some changes to improve the
> >     "default" theme (and they were a nice improvement), but not being a
> >     developer the changes weren't communicated in the form of a patch. And
> >     the changes accidentally got applied to the wrong theme: the default one
> >     (yes, there was a theme named "default" which was not the default
> >     theme). Now, basically no one used the default theme because it was so
> >     hideously ugly. I think we suffered from a case of not being able to
> >     change the default (again?) because no one could get an agreement on
> >     what the default should be. Who did actually use the default theme,
> >     though? The person writing the release notes (though they only used it
> >     for taking screenshots to include in the release notes, and otherwise
> >     used some other theme). So, with people under pressure for an imminent
> >     release, there were screenshots that looked like garbage, and
> >     investigation eventually uncovered that it was due to changes that were
> >     meant for the "default" theme having accidentally been applied to the
> >     default theme. It could have just been an amusing story if not for the
> >     other unfortunate factors happening around the same time and the heated
> >     and protracted flamewars that erupted.
> >
> >     Don't name settings/themes/things "default" if it describes something
> >     specific, since someone may come along and decide that something else
> >     should be the default, and then you're stuck with a non-default
> >     "default". Sadly, the name was already picked and documented so for
> >     backward compatibility we need to support it...
>
> Funny story, I think this is only going to bite us if we don't switch
> the default over along with promoting this out of feature.experimental.
>
> 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).
"""

features.experimental turns on "skipping" as the default behavior, and
that text clearly rules out the possibility that "default" could be
used to mean "skipping".  So, if that experimental feature graduates,
then the default behavior of fetch.negotiationAlgorithm will NOT be
the "default" behavior of fetch.negotationAlgorithm.

> In our case it's more of a story about the inconsistencies in our config
> space, i.e. some values you can't reset at all, some take empty values
> to do so, others "default" etc.
>
> > diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> > index f0dc4e69686..37958a376ca 100755
> > --- a/t/t5500-fetch-pack.sh
> > +++ b/t/t5500-fetch-pack.sh
> > @@ -928,6 +928,7 @@ test_expect_success 'fetching deepen' '
> >  '
> >
> >  test_expect_success 'use ref advertisement to prune "have" lines sent' '
> > +     test_when_finished rm -rf clientv0 clientv2 &&
> >       rm -rf server client &&
> >       git init server &&
> >       test_commit -C server both_have_1 &&
> > @@ -960,6 +961,45 @@ test_expect_success 'use ref advertisement to prune "have" lines sent' '
> >       ! grep "have $(git -C client rev-parse both_have_2^)" trace
> >  '
> >
> > +test_expect_success 'same as last but with config overrides' '
>
> Since it's the same as the preceding test, maybe we can squash this in
> to avoid the duplication? This works for me.
>
> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index 37958a376ca..3fb20eeec7e 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
> @@ -927,7 +927,7 @@ test_expect_success 'fetching deepen' '
>         )
>  '
>
> -test_expect_success 'use ref advertisement to prune "have" lines sent' '
> +test_negotiation_algorithm_default () {
>         test_when_finished rm -rf clientv0 clientv2 &&
>         rm -rf server client &&
>         git init server &&
> @@ -946,7 +946,7 @@ test_expect_success 'use ref advertisement to prune "have" lines sent' '
>
>         rm -f trace &&
>         cp -r client clientv0 &&
> -       GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv0 \
> +       GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv0 $@ \
>                 fetch origin server_has both_have_2 &&
>         grep "have $(git -C client rev-parse client_has)" trace &&
>         grep "have $(git -C client rev-parse both_have_2)" trace &&
> @@ -954,50 +954,17 @@ test_expect_success 'use ref advertisement to prune "have" lines sent' '
>
>         rm -f trace &&
>         cp -r client clientv2 &&
> -       GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv2 -c protocol.version=2 \
> +       GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv2 -c protocol.version=2 $@ \
>                 fetch origin server_has both_have_2 &&
>         grep "have $(git -C client rev-parse client_has)" trace &&
>         grep "have $(git -C client rev-parse both_have_2)" trace &&
>         ! grep "have $(git -C client rev-parse both_have_2^)" trace
> -'
> -
> -test_expect_success 'same as last but with config overrides' '
> -       test_when_finished rm -rf clientv0 clientv2 &&
> -       rm -rf server client &&
> -       git init server &&
> -       test_commit -C server both_have_1 &&
> -       git -C server tag -d both_have_1 &&
> -       test_commit -C server both_have_2 &&
> -
> -       git clone server client &&
> -       test_commit -C server server_has &&
> -       test_commit -C client client_has &&
> -
> -       # In both protocol v0 and v2, ensure that the parent of both_have_2 is
> -       # not sent as a "have" line. The client should know that the server has
> -       # both_have_2, so it only needs to inform the server that it has
> -       # both_have_2, and the server can infer the rest.
> -
> -       rm -f trace &&
> -       rm -rf clientv0 &&
> -       cp -r client clientv0 &&
> -       GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv0 \
> -               -c feature.experimental=true \
> -               -c fetch.negotiationAlgorithm=default \
> -               fetch origin server_has both_have_2 &&
> -       grep "have $(git -C client rev-parse client_has)" trace &&
> -       grep "have $(git -C client rev-parse both_have_2)" trace &&
> -       ! grep "have $(git -C client rev-parse both_have_2^)" trace &&
> +}
>
> -       rm -f trace &&
> -       cp -r client clientv2 &&
> -       GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv2 -c protocol.version=2 \
> +test_expect_success 'use ref advertisement to prune "have" lines sent' '
> +       test_negotiation_algorithm_default \
>                 -c feature.experimental=true \
> -               -c fetch.negotiationAlgorithm=default \
> -               fetch origin server_has both_have_2 &&
> -       grep "have $(git -C client rev-parse client_has)" trace &&
> -       grep "have $(git -C client rev-parse both_have_2)" trace &&
> -       ! grep "have $(git -C client rev-parse both_have_2^)" trace
> +               -c fetch.negotiationAlgorithm=default

I think you accidentally dropped one of the two tests by turning it
into a function and then only calling it for the latter usage and not
the former, but I get your idea.  It makes sense; I'll make the
change.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 29, 2022

User Elijah Newren <newren@gmail.com> has been added to the cc: list.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 29, 2022

This branch is now known as en/fetch-negotiation-default-fix.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 29, 2022

This patch series was integrated into seen via git@7ffe623.

@gitgitgadget gitgitgadget bot added the seen label Jan 29, 2022
@gitgitgadget
Copy link

gitgitgadget bot commented Jan 29, 2022

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Fri, Jan 28 2022, Elijah Newren wrote:

> Hi Ævar,
>
> On Thu, Jan 27, 2022 at 11:54 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
> [...]
>>> > Technically, before commit 3050b6dfc75d, repo-settings would treat any
>> > fetch.negotiationAlgorithm value other than "skipping" or "noop" as a
>> > request for "default", but I think it probably makes more sense to
>> > ignore such broken requests and leave fetch.negotiationAlgorithm with
>> > the default value rather than the value of "default".  (If that sounds
>> > confusing, note that "default" is usually the default value, but when
>> > feature.experimental=true, "skipping" is the default value.)
>> >
>> > [...]
>> >     A long sidenote about naming things "default":
>> >
>> >     Many years ago, in the Gnome community, there was a huge fight that
>> >     erupted, in part due to confusion over "default". There was a journalist
>> >     who had been a designer in a past life, who had a little friction with
>> >     the rest of the community, but intended well and generally improved
>> >     things. At some point, they suggested some changes to improve the
>> >     "default" theme (and they were a nice improvement), but not being a
>> >     developer the changes weren't communicated in the form of a patch. And
>> >     the changes accidentally got applied to the wrong theme: the default one
>> >     (yes, there was a theme named "default" which was not the default
>> >     theme). Now, basically no one used the default theme because it was so
>> >     hideously ugly. I think we suffered from a case of not being able to
>> >     change the default (again?) because no one could get an agreement on
>> >     what the default should be. Who did actually use the default theme,
>> >     though? The person writing the release notes (though they only used it
>> >     for taking screenshots to include in the release notes, and otherwise
>> >     used some other theme). So, with people under pressure for an imminent
>> >     release, there were screenshots that looked like garbage, and
>> >     investigation eventually uncovered that it was due to changes that were
>> >     meant for the "default" theme having accidentally been applied to the
>> >     default theme. It could have just been an amusing story if not for the
>> >     other unfortunate factors happening around the same time and the heated
>> >     and protracted flamewars that erupted.
>> >
>> >     Don't name settings/themes/things "default" if it describes something
>> >     specific, since someone may come along and decide that something else
>> >     should be the default, and then you're stuck with a non-default
>> >     "default". Sadly, the name was already picked and documented so for
>> >     backward compatibility we need to support it...
>>
>> Funny story, I think this is only going to bite us if we don't switch
>> the default over along with promoting this out of feature.experimental.
>>
>> 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).
> """
>
> features.experimental turns on "skipping" as the default behavior, and
> that text clearly rules out the possibility that "default" could be
> used to mean "skipping".  So, if that experimental feature graduates,
> then the default behavior of fetch.negotiationAlgorithm will NOT be
> the "default" behavior of fetch.negotationAlgorithm.

I see what you mean, and I'm aware that I'm debating this with a native
speaker :)

FWIW I didn't read it that way, earlier it discusses "skipping", and
here it's describing what the default is. But especially since you'd
have no reason to set this except to "reset to default" I didn't take it
to be a promise that the default wouldn't change.

I.e. maybe we'll just make it "skipping" and drop the current "default"
code, or we'll give the current "default" a name at that point.

But I do see how us not having a name for the "defult" complicates that
view of the world. For grep.patternType we've got the same thing, but
"default" there is "basic", so that's a bit different.

I do read log.date's "default" as being the sort of GNOME case you're
describing however. But I don't think we'd ever change the default
there, a date format is too subjective, whereas an internal algorithm is
liable to change.

But I think we should just change this to make it explicit (separate
from this narrow bugfix). Maybe "exhaustive" would be a good permanent
name for the default algorithm?

>> In our case it's more of a story about the inconsistencies in our config
>> space, i.e. some values you can't reset at all, some take empty values
>> to do so, others "default" etc.
>> [...]
>>
>> Since it's the same as the preceding test, maybe we can squash this in
>> to avoid the duplication? This works for me.
>> [...]
>> -       rm -f trace &&
>> -       cp -r client clientv2 &&
>> -       GIT_TRACE_PACKET="$(pwd)/trace" git -C clientv2 -c protocol.version=2 \
>> +test_expect_success 'use ref advertisement to prune "have" lines sent' '
>> +       test_negotiation_algorithm_default \
>>                 -c feature.experimental=true \
>> -               -c fetch.negotiationAlgorithm=default \
>> -               fetch origin server_has both_have_2 &&
>> -       grep "have $(git -C client rev-parse client_has)" trace &&
>> -       grep "have $(git -C client rev-parse both_have_2)" trace &&
>> -       ! grep "have $(git -C client rev-parse both_have_2^)" trace
>> +               -c fetch.negotiationAlgorithm=default
>
> I think you accidentally dropped one of the two tests by turning it
> into a function and then only calling it for the latter usage and not
> the former, but I get your idea.  It makes sense; I'll make the
> change.

Ah yes, oops. Yes we should clearly have the non-"-c [...]" case too
(and it's what I was aiming for) :)

@newren newren force-pushed the fix-fetch-negotiation-algorithm-equals-default branch from 9c592ba to 633c873 Compare January 29, 2022 07:46
@newren
Copy link
Author

newren commented Jan 29, 2022

That t3705 test failing on "CI / win+VS test (8)" has been discussed on the mailing list and is independent of this series.

@newren
Copy link
Author

newren commented Jan 29, 2022

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 29, 2022

Submitted as pull.1131.v2.git.1643478692337.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v2

To fetch this version to local tag pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v2:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v2

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 31, 2022

On the Git mailing list, Junio C Hamano wrote (reply to this):

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.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 31, 2022

On the Git mailing list, Elijah Newren wrote (reply to this):

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.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 31, 2022

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


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"?

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 31, 2022

On the Git mailing list, Elijah Newren wrote (reply to this):

On Mon, Jan 31, 2022 at 1:17 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> 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"?

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?

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 31, 2022

On the Git mailing list, Junio C Hamano wrote (reply to this):

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

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

Skipping and the other one are both commit graph walkers.  The
traditional one reports each and every commit without skipping, so
if the negation in "non-skipping" turns out to be problematic in
naming, perhaps we can say "consecutive" vs "skipping" as the
differentiator between the two?

> 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 :)

It is good to anticipate that somebody cleverly invents negotiator
that is not based on "commit walker" concept ;-)

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 31, 2022

This patch series was integrated into seen via git@6f3aa4f.

In commit 3050b6d (repo-settings.c: simplify the setup,
2021-09-21), the branch for handling fetch.negotiationAlgorithm=default
was deleted.  Since this value is documented in
Documentation/config/fetch.txt, restore the check for this value.

Note that this change caused an observable bug: if someone sets
feature.experimental=true in config, and then passes "-c
fetch.negotiationAlgorithm=default" on the command line in an attempt to
override the config, then the override is ignored.  Fix the bug by not
ignoring the value of "default".

Technically, before commit 3050b6d, repo-settings would treat any
fetch.negotiationAlgorithm value other than "skipping" or "noop" as a
request for "default", but I think it probably makes more sense to
ignore such broken requests and leave fetch.negotiationAlgorithm with
the default value rather than the value of "default".  (If that sounds
confusing, note that "default" is usually the default value, but when
feature.experimental=true, "skipping" is the default value.)

Signed-off-by: Elijah Newren <newren@gmail.com>
In commit af3a67d ("negotiator: unknown fetch.negotiationAlgorithm
should error out", 2018-08-01), error handling for an unknown
fetch.negotiationAlgorithm was added with the code die()ing.  This was
also added to the documentation for the fetch.negotiationAlgorithm
option, to make it explicit that the code would die on unknown values.

This behavior was lost with commit aaf633c ("repo-settings: create
feature.experimental setting", 2019-08-13).  Restore it so that the
behavior again matches the documentation.

Signed-off-by: Elijah Newren <newren@gmail.com>
@newren newren force-pushed the fix-fetch-negotiation-algorithm-equals-default branch from 633c873 to 7b28c52 Compare February 1, 2022 05:50
@newren
Copy link
Author

newren commented Feb 1, 2022

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 1, 2022

Submitted as pull.1131.v3.git.1643734828.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v3

To fetch this version to local tag pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v3:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v3

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 1, 2022

On the Git mailing list, Jonathan Tan wrote (reply to this):

Elijah Newren <newren@gmail.com> writes:
> Maybe Jonathan also has ideas/preferences, since he wrote the "skipping" code?

No preferences - I think both "consecutive" and "exhaustive" make sense.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 1, 2022

User Jonathan Tan <jonathantanmy@google.com> has been added to the cc: list.

repo-settings.c Show resolved Hide resolved
repo-settings.c Show resolved Hide resolved
@gitgitgadget
Copy link

gitgitgadget bot commented Feb 2, 2022

This patch series was integrated into seen via git@5699f4c.

Give the traditional default fetch.negotiationAlgorithm the name
'consecutive'.  Also allow a choice of 'default' to have Git decide
between the choices (currently, picking 'skipping' if
feature.experimental is true and 'consecutive' otherwise).  Update the
documentation accordingly.

Signed-off-by: Elijah Newren <newren@gmail.com>
@newren newren force-pushed the fix-fetch-negotiation-algorithm-equals-default branch from 7b28c52 to 7500a4d Compare February 2, 2022 02:34
@newren
Copy link
Author

newren commented Feb 2, 2022

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 2, 2022

Submitted as pull.1131.v4.git.1643773361.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v4

To fetch this version to local tag pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v4:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-1131/newren/fix-fetch-negotiation-algorithm-equals-default-v4

@@ -56,18 +56,19 @@ fetch.output::
OUTPUT in linkgit:git-fetch[1] for detail.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> diff --git a/repo-settings.c b/repo-settings.c
> index 41e1c30845f..b4fbd16cdcc 100644
> --- a/repo-settings.c
> +++ b/repo-settings.c
> @@ -26,7 +26,7 @@ void prepare_repo_settings(struct repository *r)
>  	/* Defaults */
>  	r->settings.index_version = -1;
>  	r->settings.core_untracked_cache = UNTRACKED_CACHE_KEEP;
> -	r->settings.fetch_negotiation_algorithm = FETCH_NEGOTIATION_DEFAULT;
> +	r->settings.fetch_negotiation_algorithm = FETCH_NEGOTIATION_CONSECUTIVE;
>  
>  	/* Booleans config or default, cascades to other settings */
>  	repo_cfg_bool(r, "feature.manyfiles", &manyfiles, 0);
> @@ -81,12 +81,15 @@ void prepare_repo_settings(struct repository *r)
>  	}
>  
>  	if (!repo_config_get_string(r, "fetch.negotiationalgorithm", &strval)) {
> +		int fetch_default = r->settings.fetch_negotiation_algorithm;
>  		if (!strcasecmp(strval, "skipping"))
>  			r->settings.fetch_negotiation_algorithm = FETCH_NEGOTIATION_SKIPPING;
>  		else if (!strcasecmp(strval, "noop"))
>  			r->settings.fetch_negotiation_algorithm = FETCH_NEGOTIATION_NOOP;
> +		else if (!strcasecmp(strval, "consecutive"))
> +			r->settings.fetch_negotiation_algorithm = FETCH_NEGOTIATION_CONSECUTIVE;
>  		else if (!strcasecmp(strval, "default"))
> -			r->settings.fetch_negotiation_algorithm = FETCH_NEGOTIATION_DEFAULT;
> +			r->settings.fetch_negotiation_algorithm = fetch_default;
>  		else
>  			die("unknown fetch negotiation algorithm '%s'", strval);
>  	}

This 

    - set the default to whatever experimental says
    - parse the configuration and set it 
      - to the specified value unless it is DEFAULT
      - to the value the experimental bit set as the default otherwise

certainly works, even though I find it a bit convoluted and
backwards.  I have slight preference to "if the user says 'default',
hold onto it as a symbolic 'default' setting, and resolve it to a
concrete value at the very end" pattern, which tends to handle the
"reverting to default" case better.

There is the "manyfiles" precedent that sets index.version and
core.untrackedCache irreversibly nearby, and I am sympathetic to
whoever added the fetch_negotiation_algorithm support (it probably
is not you, I am guessing) by mimicking it, so I am OK with the
version posted as-is.

Thanks.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 2, 2022

This patch series was integrated into seen via git@e2a55cc.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 3, 2022

This patch series was integrated into seen via git@66b4ab0.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 4, 2022

There was a status update in the "New Topics" section about the branch en/fetch-negotiation-default-fix on the Git mailing list:

Fix interaction between fetch.negotiationAlgorithm and
feature.experimental configuration variables.

Will merge to 'next'.
source: <pull.1131.v4.git.1643773361.gitgitgadget@gmail.com>

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 4, 2022

This patch series was integrated into seen via git@dd5cdf6.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 5, 2022

This patch series was integrated into seen via git@8b3421c.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 8, 2022

This patch series was integrated into seen via git@a0685ea.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 8, 2022

This patch series was integrated into next via git@95a8a91.

@gitgitgadget gitgitgadget bot added the next label Feb 8, 2022
@gitgitgadget
Copy link

gitgitgadget bot commented Feb 9, 2022

This patch series was integrated into seen via git@d35c718.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 10, 2022

There was a status update in the "Cooking" section about the branch en/fetch-negotiation-default-fix on the Git mailing list:

Fix interaction between fetch.negotiationAlgorithm and
feature.experimental configuration variables.

Will merge to 'master'.
source: <pull.1131.v4.git.1643773361.gitgitgadget@gmail.com>

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 10, 2022

This patch series was integrated into seen via git@04c7851.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 13, 2022

This patch series was integrated into seen via git@a4dae70.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 15, 2022

This patch series was integrated into seen via git@6afdf51.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 15, 2022

There was a status update in the "Cooking" section about the branch en/fetch-negotiation-default-fix on the Git mailing list:

Fix interaction between fetch.negotiationAlgorithm and
feature.experimental configuration variables.

Will merge to 'master'.
source: <pull.1131.v4.git.1643773361.gitgitgadget@gmail.com>

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 16, 2022

This patch series was integrated into seen via git@2cb54d5.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 17, 2022

This patch series was integrated into seen via git@70ff41f.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 17, 2022

This patch series was integrated into master via git@70ff41f.

@gitgitgadget
Copy link

gitgitgadget bot commented Feb 17, 2022

This patch series was integrated into next via git@70ff41f.

@gitgitgadget gitgitgadget bot added the master label Feb 17, 2022
@gitgitgadget gitgitgadget bot closed this Feb 17, 2022
@gitgitgadget
Copy link

gitgitgadget bot commented Feb 17, 2022

Closed via 70ff41f.

@newren newren deleted the fix-fetch-negotiation-algorithm-equals-default branch February 17, 2022 02:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant