On Tue, Mar 27, 2018 at 5:07 PM, Jonathan Tan <jonathantanmy@xxxxxxxxxx> wrote:
> s/submoduled/submodules
> s/superprojects/superproject's/
> s/and //
>
> s/force/forcing/
All wording fixed.
>> + sub_path = sub_worktree + strlen(super_worktree) + 1;
>> +
>> + if (repo_submodule_init(&subrepo, superproject, sub_path))
>> + return;
>> +
>> + repo_read_index(&subrepo);
>
> From the name of this function and its usage in
> connect_work_tree_and_git_dir(), I expected this function to just
> iterate through all the files in its workdir (which it is doing in the
> "for" loop below) and connect any nested submodules. Why does it need
> access to its superproject? (I would think that repo_init() would be
> sufficient here instead of repo_submodule_init().)
Testing validates your thinking (for now).
If we ever want to have good error reporting (see bmwills hint to
check for index corruption), we may want to have all the repos constructed
as submodules from the_repository, as then the error messages might
be better (e.g. in the future we could display the
"submodule nesting stack").
I'll remove the superproject argument for now.
>> +
>> + strbuf_reset(&sub_wt);
>> + strbuf_addf(&sub_wt, "%s/%s/.git", sub_worktree, sub->path);
>> +
>> + strbuf_reset(&sub_gd);
>> + strbuf_addf(&sub_gd, "%s/modules/%s", sub_gitdir, sub->name);
>> +
>> + strbuf_setlen(&sub_wt, sub_wt.len - strlen("/.git"));
>> +
>> + if (is_submodule_active(&subrepo, ce->name)) {
>> + connect_work_tree_and_git_dir(sub_wt.buf, sub_gd.buf, 0);
>> + connect_wt_gitdir_in_nested(sub_wt.buf, sub_gd.buf, &subrepo);
>
> The modifications of sub_wt and sub_gd should probably go here, since
> they are not used unless this "if" block is executed.
Thanks! I also cut out the setlen call by giving the correct format string.
(The code presented here is not very old, I just fired it off as soon as the
test passed)
>
>> +void connect_work_tree_and_git_dir(const char *work_tree_,
>> + const char *git_dir_,
>> + int recurse_into_nested)
>
> How is this function expected to be used? From what I see:
> - if recurse_into_nested is 0, this works regardless of whether the
> work_tree_ and git_dir_ is directly or indirectly a submodule of
> the_repository
> - if recurse_into_nested is 1, work_tree_ and git_dir_ must be directly
> a submodule of the_repository (since it is referenced directly)
>
> This seems confusing - is this expected?
In the next revision of the series connect_wt_gitdir_in_nested
will no longer have a third argument for the repo, as we use repo_init.
That eases the handling a bit here.
