Re: [PATCH v2 5/5] doc: --recurse-submodules only apply to active submodules

From: Damien Robert <damien.olivier.robert@gmail.com>
Date: Mar 20, 2020, 22:23 UTC
Message-ID: <20200320222328.lynvrgqc35pvxxnl@doriath>
In-Reply-To: <EA460350-CF54-4B91-B1F0-6C4692A14B88@gmail.com>

From Philippe Blain, Thu 05 Mar 2020 at 23:17:54 (-0500) :

> In the commit title: s/apply/applies

Oups, missed this one.

> Initialized, active and populated, as far as I understand, are three different concepts.

[...]

Show 8 quoted lines

> From what I understand of the code, git-fetch really recurses into *populated* submodules,
> and does not consult the submodule.active or submodule.<name>.active config settings.
> If you look at builtin/fetch.c::cmd_fetch, and the functions it calls, but is_submodule_active is not in the call chain.
> I tested that setting submodule.<name>.active to false and calling 
> 
>     git fetch --recurse-submodules=yes
> 
> still fetches in the submodule(s). So this should stay as "populated".

Thanks for the thorough review! I had tested that `git-pull` was only updating the worktree of active submodules, but missed that it was still fetching non active submodules.

In light of this I think this is even more important to mention which command affects which submodules in the doc.

Show 6 quoted lines

> That's only partly correct: I tested setting submodule.<name>.active to false and doing
> 
>     git pull --recurse-submodules
> 
> This does fetches the submodule but does not update its working tree, due to the call to 
> is_submodule_active in prepare_to_clone_next_submodule in builtin/submodule--helper.c

I still left 'active submodule' here in order to not render the formulation too heavy. Since it is implicit that `pull` goes through fetch, I hope it is clear that the fetching still involves all populated submodules.

-- 
Damien Robert
http://www.normalesup.org/~robert/pro