On Tue, 27 Mar 2018 14:39:18 -0700
Stefan Beller <sbel...@google.com> wrote:
> connect_work_tree_and_git_dir is used to connect a submodule worktree with
> its git directory and vice versa after events that require a reconnection
> such as moving around the working tree. As submodules can have nested
> submoduled themselves, we'd also want to fix the nested submodules when
s/submoduled/submodules
> asked to. Add an option to recurse into the nested submodules and connect
> them as well.
>
> As submodules are identified by their name (which determines their git
> directory in relation to their superprojects git directory) internally
s/superprojects/superproject's/
> and by their path in the working tree of the superproject, we need to
> make sure that the mapping of name <-> path is kept intact. We can do
> that in the git-mv command by writing out the gitmodules file and first
s/and //
> and then force a reload of the submodule config machinery.
s/force/forcing/
>
> Signed-off-by: Stefan Beller <sbel...@google.com>
[snip]
> +static void connect_wt_gitdir_in_nested(const char *sub_worktree,
> + const char *sub_gitdir,
> + struct repository *superproject)
> +{
> + int i;
> + struct repository subrepo;
> + struct strbuf sub_wt = STRBUF_INIT;
> + struct strbuf sub_gd = STRBUF_INIT;
> + const struct submodule *sub;
> + const char *super_worktree,
> + *sub_path; /* path inside the superproject */
> +
> + /* subrepo got moved, so superproject has outdated information */
> + submodule_free(superproject);
> +
> + super_worktree = real_pathdup(superproject->worktree, 1);
> +
> + 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().)
> +
> + for (i = 0; i < subrepo.index->cache_nr; i++) {
> + const struct cache_entry *ce = subrepo.index->cache[i];
> +
> + if (!S_ISGITLINK(ce->ce_mode))
> + continue;
> +
> + while (i + 1 < subrepo.index->cache_nr &&
> + !strcmp(ce->name, subrepo.index->cache[i + 1]->name))
> + /*
> + * Skip entries with the same name in different stages
> + * to make sure an entry is returned only once.
> + */
> + i++;
> +
> + sub = submodule_from_path(&subrepo, &null_oid, ce->name);
> + if (!sub)
> + /* submodule not checked out? */
> + continue;
> +
> + 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.
> +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?
