On Thu, Apr 13, 2017 at 12:05 PM, Brandon Williams <bmwill@xxxxxxxxxx> wrote:
> 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