Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > 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. As the function this new thing is added assumes the modern layout of having submodule "repository" in .git/modules/* of the repository of the superproject, it is rather easy to move the whole thing together, so recording it as relative path is all the more important. Can a submodule repository be bound to two or more superproject at the same time? "We assume no, and we will forbid such a layout, and that is why we can afford to make submodules aware of their superprojects" is a totally acceptable answer, but it would make it easier to follow the reasoning behind a design change like this series does if such an assumption is recorded somewhere. > + git_config_set_in_file(p, "submodule.superprojectGitdir", > + relative_path(absolute_path(get_git_dir()), > + path, &sb)); > + OK, so even when the superproject is used as a submodule of somebody else, we could get to the top of its working tree, because (1) the submodule we are currently working in can find out where the gitdir of the superproject is, and (2) in that gitdir, which is very likely different from the ".git/" subdirectory of the working tree of the superproject (instead, it would be a directory in ".git/modules/" of its superproject), we could find the core.worktree configuration to reach the working tree of the superproject. OK, makes sense. Thanks.
