$subject, which I started looking at because in 4f3e57ef13d
(submodule--helper: advise on fatal alternate error, 2019-12-02) the
scaffolding was set up to read config, but nothing actually did so. So
"advice.submoduleAlternateErrorStrategyDie=false" has never worked. That
can be tested with:
diff --git a/t/t7408-submodule-reference.sh b/t/t7408-submodule-reference.sh
index a3892f494b6..8918be9ef5c 100755
--- a/t/t7408-submodule-reference.sh
+++ b/t/t7408-submodule-reference.sh
@@ -193,7 +193,7 @@ test_expect_success 'missing nested submodule alternate fails clone and submodul
cd supersuper-clone &&
check_that_two_of_three_alternates_are_used &&
# update of the submodule fails
- test_must_fail git submodule update --init --recursive
+ git -c advice.submoduleAlternateErrorStrategyDie=false submodule update --init --recursive
)
'
More generally, the advice API should be made to panic in
advice_if_enabled() if nothing has read the advice config, which would
turns up a lot of other such issues. I can't think of an easy way to
check for that. We could add a BUG() on:
if (!the_repository->config && !the_repository->config->hash_initialized)
In advice_enabled(), but that wouldn't catch things that have read the
config, but which aren't actually using it to check the advice config.
Probably the inverse would be a good approach, adding a
advice.default=false to turn them all off by default, and then BUG() if
we ever end up emitting advice anywhere (except if other specific config
told us to enable it).
