Re: [PATCH 2/4] submodule.c: uninitialized submodules are ignored in recursive commands

From: Stefan Beller <sbeller@google.com>
Date: Apr 13, 2017, 19:12 UTC
Message-ID: <CAGZ79kZybFNPPAuw4GmVUSmQVBcCG402uCur8M9hSoY3CbhbXw@mail.gmail.com>
In-Reply-To: <20170413190541.GD96917@google.com>

On Thu, Apr 13, 2017 at 12:05 PM, Brandon Williams <bmwill@google.com> wrote:

Show 8 quoted lines

> On 04/11, Stefan Beller wrote:
>> This was an oversight when working on the working tree modifying commands
>> recursing into submodules.
>>
>> To test for uninitialized submodules, introduce another submodule, that is
>> uninitialized in the actual tests. By adding it to the branch "add_sub1",
>> which is the starting point of all other branches, we have wide coverage.
>>

...

>
> The 'submodule add' command will make the submodule active, so you'll
> need to add in a line to subsequently make the submodule inactive for
> this to work, unless you do in at a later point in time.

Yes, it will make it active, but that doesn't matter here, because at this point (in create_lib_submodule_repo) we prepare an upstream in submodule_update_repo

Any later test follows the structure of

    prolog &&
    reset_work_tree_to no_submodule &&
    (
        cd submodule_update &&
        # do actual test here, in submodule_update
    )

Note that 'prolog' performs a clone of submodule_update_repo to submodule_update, manually setting 'sub1' to active.

'uninitialized_sub' is not active.

I tried to explain it via
    To test for uninitialized submodules, introduce another submodule,
    that is uninitialized in the actual tests.
in the commit message, but that is too concise apparently.
So the resend will explain that a bit more.

Thanks, Stefan