Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes:
>> Clearing the variable from "super" is technically wrong because the
>> repository is set up as a submodule of "recursivesuper" and if we
>> had further tests, we should restore it in "super", but the point is
>> that we are makng sure "git submodule update" sets the variable in
>> the configuration file of the submodule, and not in the superproject's.
If we wanted to be kosher about this, we could start the test with
git config submodule.hassuperproject 1
in the "super" repository, clear the variable in the "submodule"
repository, before running the "git submodule update" step, which
(1) should not touch the "super" configuration and (2) should touch
the "submodule" configuration.
If we inspect in the "super" repository after "submodule update"
value=$(git config submodule.hassuperproject) &&
test "$value" = 1
I think we can tell if a buggy "submodule update" overwrites the
"super" configuration from "1" to "true". And downstream tests
will take "1" as true just fine.
And of course, in "submodule", the variable after "submodule update"
must be set to true, which can be checked with
value=$(git -C submodule config --type=bool submodule.hassuperproject) &&
test "$value" = true
The trick depends on the hardcoded value to represent "true" in the
code this patch adds, but that is the canonical way to spell true in
the config, according to "git config --type=bool", so the dependency
may not be too bad.
Just a thought.
