Re: [PATCH v9 2/3] introduce submodule.hasSuperproject record

Emily Shaffer [off-list ref] writes:

quoted

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.