Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > 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. And by using the path from gitdir to gitdir, we can > move the submodule within the superproject's tree structure without > breaking the submodule's cache, too. All of the above explains what the design choice is, and what benefit the chosen design brings us. But this last one ... > Finally, by pointing at "get_git_common_dir()" instead of > "get_git_dir()", we ensure the link will refer to the parent repo, > not to a specific worktree. ... only says that we choose to point at the common one, not a specific worktree (i.e. what behaviour was chosen by the design), but it is left unclear what benefit it is trying to bring us. Thinking aloud, imagine that there are two worktrees for the superproject. For simplicity, let's further imagine that these worktrees have a clean check-out of the same commit, hence, these two worktrees have the same commit from the same submodule checked out at the same location relative to the project root. The subdirectory in each of these two superproject worktrees that checks out the submodule has .git file (as we "absorb" the gitdir in the modern submodule layout) pointing at somewhere. It probably is OK if they point at the same place, but it might be more natural if these two submodule checkouts are two worktrees for a single submodule repository (this part I am not very clear, and that is why I labeled the discussion "thinking aloud"). It seems to me that both design choices would have equally valid arguments for them. If both of these submodule worktrees point at the "common" dir of the superproject, because the "common" one is part of the primary worktree, which is harder to lose than secondary worktrees, of the superproject, it is presumably harder to go stale when "worktree rm" is done at superproject, which may be a plus. But then from the "cached" pointer, each of these submodule worktrees cannot tell which worktree of the superproject they are checked out as a part of. Of course we can go to the root level of the submodule worktree and do the usual repository discovery to learn where the root level of the superproject worktree it belongs to, but it somehow feels that it defeats half the point of having this "cache" information. If we instead point at the git-dir, from there, it is just one level of indirection to find out where the common dir of the superproject is. > If the new config is present, we can do some optional value-added > behavior, like letting "git status" print additional info about the > submodule's status in relation to its superproject, or like letting the > superproject and submodule share an additional config file separate from > either one's local config. And one value-add that I would think of off the top of my head is to show "we have commit X checked out, which is 4 commits on top of what the superproject's index records for this submodule" when "git status" is run in the submodule's worktree. I do not know that is an operation to specifically optimize for, but by choosing to "cache" the common dir, not the one specific to the worktree of the superporject our submodule checkout is a part of, the chosen design seems to make it harder to implement? Thanks.
