@@ -2236,7 +2236,7 @@ void absorb_git_dir_into_superproject(const char *path,
}
}
-int get_superproject_working_tree(struct strbuf *buf)
+static int get_superproject_working_tree_from_fs(struct strbuf *buf)
{
struct child_process cp = CHILD_PROCESS_INIT;
struct strbuf sb = STRBUF_INIT;
@@ -2320,6 +2320,89 @@ int get_superproject_working_tree(struct strbuf *buf)
return ret;
}
+int get_superproject_working_tree(struct strbuf *buf)
+{
+ char *super_gitdir = NULL;
+ const char *cwd = xgetcwd();
+ struct child_process cp = CHILD_PROCESS_INIT;
+ struct strbuf absolute_super_gitdir = STRBUF_INIT;
+ struct strbuf out = STRBUF_INIT;
+ struct string_list lines = STRING_LIST_INIT_NODUP;
+ struct string_list_item *it = NULL;
+ const char *wt_prefix = "worktree ";
+ int rc = 0;
+
+
+ /* Do we know we have a superproject? */
+ if (git_config_get_string("submodule.superprojectgitdir", &super_gitdir))
+ goto fallback;
+
+ strbuf_addf(&absolute_super_gitdir, "%s/%s", get_git_dir(), super_gitdir);
+
+ /*
+ * NEEDSWORK: This is a child process call because worktree.c still
+ * relies heavily on the_repository. If we can make worktree.c work with
+ * a repository object - or, better yet, a gitdir path alone - then we
+ * can drop the child process and ask worktree.c directly.
+ *
+ * Alternatively, if 'git worktree' learns a way to say 'the worktree
+ * associated with this gitdir' instead of 'all worktrees', that would
+ * be clearer because we could skip the foreach below.
+ */
+
+ /* Get the output of `git worktree list` from that superproject */
+ prepare_other_repo_env(&cp.env_array, absolute_super_gitdir.buf);
+ strvec_pushl(&cp.args, "-C", absolute_super_gitdir.buf, "worktree", "list",
+ "--porcelain", NULL);
+
+ cp.git_cmd = 1;
+ if (capture_command(&cp, &out, 0) ||
+ !string_list_split_in_place(&lines, out.buf, '\n', -1))
+ die("submodule.superprojectGitDir is stale; run 'git submodule "
+ "update' from the superproject.");
+
+ for_each_string_list_item(it, &lines) {
+ char *trimmed;
+ /*
+ * Lines containing worktree dirs look like
+ * 'worktree /some/path'
+ */
+ if (strncmp(it->string, wt_prefix, strlen(wt_prefix)))
+ continue;
+ trimmed = it->string + strlen(wt_prefix);
+
+ /*
+ * '/some/path/to/sub' is a prefix of '/some/path' - that's our
+ * worktree
+ */
+ if (!strncmp(cwd, trimmed, strlen(trimmed))) {
+ strbuf_addstr(buf, trimmed);
+ rc = 1;
+ goto cleanup;
+ }
+ }
+
+fallback:
+ /*
+ * Because a submodule may have been created before
+ * submodule.superprojectGitDir was introduced, fall back on checking
+ * whether ../ is the superproject.
+ */
+ trace2_data_intmax("submodule", the_repository,
+ "get_superproject_wt/config_missing", rc);
+ rc = get_superproject_working_tree_from_fs(buf);
+
+ /*
+ * NEEDSWORK: Is it possible to teach a submodule the path to its
+ * superproject when this happens?
+ */
+
+cleanup:
+ string_list_clear(&lines, 0);
+ strbuf_release(&out);
+ return rc;
+}
+
/*
* Put the gitdir for a submodule (given relative to the main
* repository worktree) into `buf`, or return -1 on error.
@@ -247,6 +247,15 @@ test_expect_success 'showing the superproject correctly' '
test_cmp expect out
'
+test_expect_success 'show the superproject correctly without superprojectGitDir' '
+ # repos created before submodule.superprojectGitDir was introduced which
+ # have not been `git submodule update`-ed lately must not break
+ git -C super/dir/sub config --unset submodule.superprojectGitDir &&
+ echo $(pwd)/super >expect &&
+ git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
+ test_cmp expect out
+'
+
# at least one external project depends on this behavior:
test_expect_success 'rev-parse --since= unsqueezed ordering' '
x1=--since=1970-01-01T00:00:01Z &&
Now that submodule.superprojectGitDir is being treated as the point of truth for whether a repo is a submodule or not, let's use it in `git rev-parse --show-superproject-working-tree`. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> --- This commit may be more of an RFC - to demonstrate what life looks like if we use submodule.superprojectGitDir as the source of truth. But since 'git rev-parse --show-superproject-working-tree' is used in a lot of scripts in the wild[1], I'm not so sure it's a great example. To be honest, I'd prefer to die("Try running 'git submodule update'") here, but I don't think that's very script-friendly. However, falling back on the old implementation kind of undermines the idea of treating submodule.superprojectGitDir as the point of truth. One thought I did have was to put that error message in builtin/rev-parse.c instead, and print it to stderr (per usual with user-visible messages) so it doesn't interfere with scripts, but gives a hint for debugging. Another thought - captured by the NEEDSWORK in the diff - was that we could "heal" by adding that config after we know the worktree of the superproject. Or, it could be that it won't be a problem for a long time, as anybody running 'git submodule update' will eventually have that config specified - that's why I included the traces, so we could try and get an understanding of how long repos remain in this state where they have submodules but nobody ran 'git submodule update'. But that will only give me visibility into submodule users at Google, who we expect to be making a lot of workflow changes soon, anyway. 1: https://github.com/search?q=%22--show-superproject-working-tree%22&type=code --- submodule.c | 85 +++++++++++++++++++++++++++++++++++++++++++- t/t1500-rev-parse.sh | 9 +++++ 2 files changed, 93 insertions(+), 1 deletion(-)