On Tue, Jun 15 2021, Emily Shaffer wrote: > Teach submodules a reference to their superproject's gitdir. This allows > us to A) know that we're running from a submodule, and B) have a > shortcut to the superproject's vitals, for example, configs. > > By using a relative path instead of an absolute path, we can move the > superproject directory around on the filesystem without breaking the > submodule's cache. > > Since this cached value is only introduced during new submodule creation > via `git submodule add`, though, there is more work to do to allow the > cache to be created at other times. > > Signed-off-by: Emily Shaffer <emilyshaffer@xxxxxxxxxx> > --- > Documentation/config/submodule.txt | 12 +++++++++ > builtin/submodule--helper.c | 4 +++ > t/t7400-submodule-basic.sh | 40 ++++++++++++++++-------------- > 3 files changed, 38 insertions(+), 18 deletions(-) > > diff --git a/Documentation/config/submodule.txt b/Documentation/config/submodule.txt > index d7a63c8c12..7c459cc19e 100644 > --- a/Documentation/config/submodule.txt > +++ b/Documentation/config/submodule.txt > @@ -90,3 +90,15 @@ submodule.alternateErrorStrategy:: > `ignore`, `info`, `die`. Default is `die`. Note that if set to `ignore` > or `info`, and if there is an error with the computed alternate, the > clone proceeds as if no alternate was specified. > + > +submodule.superprojectGitDir:: > + The relative path from the submodule's worktree to the superproject's > + gitdir. This config should only be present in projects which are > + submodules, but is not guaranteed to be present in every submodule. It > + is set automatically during submodule creation. > ++ > + In situations where more than one superproject references the same > + submodule worktree, the value of this config and the behavior of > + operations which use it are undefined. To reference a single project > + from multiple superprojects, it is better to create a worktree of the > + submodule for each superproject. > diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c > index d55f6262e9..d60fcd2c7d 100644 > --- a/builtin/submodule--helper.c > +++ b/builtin/submodule--helper.c > @@ -1910,6 +1910,10 @@ static int module_clone(int argc, const char **argv, const char *prefix) > git_config_set_in_file(p, "submodule.alternateErrorStrategy", > error_strategy); > > + git_config_set_in_file(p, "submodule.superprojectGitdir", > + relative_path(absolute_path(get_git_dir()), > + path, &sb)); > + > free(sm_alternate); > free(error_strategy); > Am I correct that what this series really does is avoid needing to: 1. Run the equivalent of $(git rev-parse --absolute-git-dir), let's call the result of that $X. 2. Feed that to the equvialent of $(git -C $X/../ rev-parse --absolute-git-dir) 3. Check if the relationship between the two is really that of a submodule, i.e. running "git submodule status", check if $X contains ".git/modules/" etc. I see an earlier iteration of this series had such a shell-out, and that this is the "cache": https://lore.kernel.org/git/20210423001539.4059524-5-emilyshaffer@xxxxxxxxxx/; and your v1 cover letter seems to support the above summary: https://lore.kernel.org/git/20210611225428.1208973-1-emilyshaffer@xxxxxxxxxx/ I think it's fine to fine to add such a cache in principle if it's needed. But I'm a bit iffy on a series that's structured in a way as to not start by asserting that we should have given semantics without the cache, and then adds the cache later as an optional optimization. Particularly as the whole submodule business is moving to C, so isn't this whole caching business something we can avoid doing, and instead just call a C function? The optimization part of this was not calling "git rev-parse" on every submodule invocation wasn't it, not avoiding a few syscalls that deal with the FS. Your initial RFC had modifications to git-submodule.sh, in the interim it seems that's been moved sufficiently to C that we're modifying just the submodule.c here. I'm not very familiar with setup_git_directory_gently_1(), discover_git_directory() etc, but wherever you are in a git worktree we'll chdir() to the top-level when running built-ins. So that gives us step #1 of the above. And #2 would be adding "/../" to the end of that path and running those functions again? Perhaps with a #3 for "is there a submodule relationship?". Even if we still have some bits in shellscript etc, couldn't we then setenv() that in some GIT_* variable, e.g. GIT_SUPERPROJECT_DIR? Or is the problem really that this isn't a cache, because we can't say with absolute certainty that there is such a gitdir/submodule relationship, except at the time of running "git submodule" in the former for some reason?
