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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 15, 2022, 19:19 UTC
Message-ID: <xmqq5yofdnws.fsf@gitster.g>
In-Reply-To: <YjDdRiRvvDtKZyq4@google.com>

Emily Shaffer <emilyshaffer@google.com> writes:

Show 5 quoted lines

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